time in threaded programs

Discussion in 'C Programming' started by JLeidel, Jan 28, 2008.

  1. JLeidel

    JLeidel Guest

    All, I've been having an interesting issue in getting some `time`
    functions to work within a threaded application. Essentially, all I'm
    doing is retieving the local time from the main thread in order to
    compare against a time offset of GMT.

    So...

    ....
    time_t cur_time = 0;
    struct tm *my_time;
    int rtn = 0;

    time( &cur_time );
    localtime_r( &cur_time, my_time );
    ....

    segfaults on the `localtime_r` call.
    compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1
    thread model is pthreads.

    any thoughts??

    cheers
    john
     
    JLeidel, Jan 28, 2008
    #1
    1. Advertising

  2. In article <>,
    JLeidel <> wrote:
    >All, I've been having an interesting issue in getting some `time`
    >functions to work within a threaded application.


    Suggest that you ask in a threads programming newsgroup.
    Threads are not part of the C language, so they are considered
    off-topic in comp.lang.c .
    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
     
    Walter Roberson, Jan 28, 2008
    #2
    1. Advertising

  3. On Sun, 27 Jan 2008 20:20:24 -0800, JLeidel wrote:y

    > All, I've been having an interesting issue in getting some `time`
    > functions to work within a threaded application. Essentially, all I'm
    > doing is retieving the local time from the main thread in order to
    > compare against a time offset of GMT.


    Were this a problem with threads or localtime_r, you would have
    gotten better answers from comp.unix.programming. Even so, it
    would have been useful to add the declaration of localtime_r
    (adding which to your post would likely have triggered the
    "oops" that you're looking for).


    > ...
    > time_t cur_time = 0;
    > struct tm *my_time;
    > int rtn = 0;
    >
    > time( &cur_time );
    > localtime_r( &cur_time, my_time );
    > ...
    >
    > segfaults on the `localtime_r` call.
    > compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1 thread model is
    > pthreads.
    >
    > any thoughts??


    localtime_r appears to require a pointer to a struct tm. You appear
    to be passing it an unitiialized pointer.

    struct tm my_time;
    ....
    localtime_r( &cur_time, &my_time );

    Martin
    --
    Martin Golding DoD #0236 |
    Always code as if the person who ends up maintaining your code will be a
    violent psychopath who knows where you live.
     
    Martin Golding, Jan 28, 2008
    #3
  4. JLeidel <> writes:
    > All, I've been having an interesting issue in getting some `time`
    > functions to work within a threaded application. Essentially, all I'm
    > doing is retieving the local time from the main thread in order to
    > compare against a time offset of GMT.
    >
    > So...
    >
    > ...
    > time_t cur_time = 0;
    > struct tm *my_time;
    > int rtn = 0;
    >
    > time( &cur_time );
    > localtime_r( &cur_time, my_time );
    > ...
    >
    > segfaults on the `localtime_r` call.
    > compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1
    > thread model is pthreads.
    >
    > any thoughts??


    If threading really were relevant to the problem, this probably
    wouldn't be the place to ask about it. Standard C defines no support
    for threading. There's a comp.programming.threads newsgroup.

    If the semantics of localtime_r were relevant to the problem, this
    probably wouldn't be the place to ask about it, since localtime_r is
    not a standard C function (though localtime is).

    But I notice that your variable my_time, as far as I can tell, has not
    been initialized when you pass it to the localtime_r function.
    Whatever localtime_r does, it's likely to use the values of its
    parameters, which is going to invoke undefined behavior. You need to
    assign some value to my_time before using it.

    (I'm assuming my_time is uninitialized; I can't be certain because you
    posted a code fragment rather than a complete program.)

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 28, 2008
    #4
  5. JLeidel

    CBFalconer Guest

    JLeidel wrote:
    >
    > All, I've been having an interesting issue in getting some `time`
    > functions to work within a threaded application. Essentially,
    > all I'm doing is retieving the local time from the main thread in
    > order to compare against a time offset of GMT.
    >
    > So...
    >
    > ...
    > time_t cur_time = 0;
    > struct tm *my_time;
    > int rtn = 0;
    >
    > time( &cur_time );
    > localtime_r( &cur_time, my_time );
    > ...
    >
    > segfaults on the `localtime_r` call.


    Bad call. From N869:

    7.23.3.4 The localtime function

    Synopsis
    [#1]
    #include <time.h>
    struct tm *localtime(const time_t *timer);

    Description

    [#2] The localtime function converts the calendar time
    pointed to by timer into a broken-down time, expressed as
    local time.

    Returns

    [#3] The localtime function returns a pointer to the broken-
    down time, or a null pointer if the specified time cannot be
    converted to local time.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jan 28, 2008
    #5
  6. JLeidel

    Ian Collins Guest

    CBFalconer wrote:
    > JLeidel wrote:
    >>
    >> time( &cur_time );
    >> localtime_r( &cur_time, my_time );
    >> ...
    >>
    >> segfaults on the `localtime_r` call.

    >
    > Bad call. From N869:
    >

    Why?

    > 7.23.3.4 The localtime function
    >
    > Synopsis
    > [#1]
    > #include <time.h>
    > struct tm *localtime(const time_t *timer);
    >
    > Returns
    >
    > [#3] The localtime function returns a pointer to the broken-
    > down time, or a null pointer if the specified time cannot be
    > converted to local time.
    >

    Which is why it is not recommended in threaded code, there is nothing to
    say whether the pointer returned points to a shared or unique
    (per-thread) object, hence the addition of the _r functions in a certain
    unmentionable standard.

    --
    Ian Collins.
     
    Ian Collins, Jan 28, 2008
    #6
  7. JLeidel

    Randy Howard Guest

    On Mon, 28 Jan 2008 00:53:32 -0600, Ian Collins wrote
    (in article <>):

    > CBFalconer wrote:
    >> JLeidel wrote:
    >>>
    >>> time( &cur_time );
    >>> localtime_r( &cur_time, my_time );
    >>> ...
    >>>
    >>> segfaults on the `localtime_r` call.

    >>
    >> Bad call. From N869:
    >>

    > Why?


    Probably due to him jumping the gun again and not seeing the _r part.


    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
     
    Randy Howard, Jan 28, 2008
    #7
  8. JLeidel wrote:
    > All, I've been having an interesting issue in getting some `time`
    > functions to work within a threaded application. Essentially, all I'm
    > doing is retieving the local time from the main thread in order to
    > compare against a time offset of GMT.


    > time_t cur_time = 0;
    > struct tm *my_time;
    > int rtn = 0;


    > time( &cur_time );
    > localtime_r( &cur_time, my_time );


    > segfaults on the `localtime_r` call.
    > compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1
    > thread model is pthreads.


    #include <time.h>
    #include <stdio.h>

    int main(void)
    {
    time_t cur_time = 0;
    struct tm *my_time;

    time(&cur_time);

    /* There is no way to tell if the OP's
    "localtime_r( &cur_time, my_time );"
    is right, since localtime_r is not
    a standard C function. It is very
    suspicious looking, since the indeterminate
    value of the pointer my_time is passed.
    'my_time' does not point to any allocated
    space, and so this argument must be completely
    useless.

    Below is not the way I would normally use
    localtime, preferring to copy the pointed
    to structure to an actually allocated one.
    Still, it will work, while the odds are
    heavily against the OP's line doing anything
    useful.
    */
    my_time = localtime(&cur_time);
    printf("ctime(&cur_time) is %s"
    "asctime(my_time) is %s.",
    ctime(&cur_time), asctime(my_time));
    return 0;
    }


    [output]
    ctime(&cur_time) is Mon Jan 28 02:28:50 2008
    asctime(my_time) is Mon Jan 28 02:28:50 2008.
     
    Martin Ambuhl, Jan 28, 2008
    #8
  9. JLeidel

    CBFalconer Guest

    Randy Howard wrote:
    > Ian Collins wrote
    >> CBFalconer wrote:
    >>> JLeidel wrote:
    >>>>
    >>>> time( &cur_time );
    >>>> localtime_r( &cur_time, my_time );
    >>>> ...
    >>>>
    >>>> segfaults on the `localtime_r` call.
    >>>
    >>> Bad call. From N869:
    >>>

    >> Why?

    >
    > Probably due to him jumping the gun again and not seeing the _r part.


    True. However I don't recall that localtime_r code was shown.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jan 28, 2008
    #9
  10. JLeidel

    Randy Howard Guest

    On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote
    (in article <>):

    > Randy Howard wrote:
    >> Ian Collins wrote
    >>> CBFalconer wrote:
    >>>> JLeidel wrote:
    >>>>>
    >>>>> time( &cur_time );
    >>>>> localtime_r( &cur_time, my_time );
    >>>>> ...
    >>>>>
    >>>>> segfaults on the `localtime_r` call.
    >>>>
    >>>> Bad call. From N869:
    >>>>
    >>> Why?

    >>
    >> Probably due to him jumping the gun again and not seeing the _r part.

    >
    > True. However I don't recall that localtime_r code was shown.


    It's in the article you quoted. And there it is again, for your
    convenience. Just look up ^^^




    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
     
    Randy Howard, Jan 30, 2008
    #10
  11. Randy Howard wrote:
    > On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote
    > (in article <>):
    >
    >> Randy Howard wrote:
    >>> Ian Collins wrote
    >>>> CBFalconer wrote:
    >>>>> JLeidel wrote:
    >>>>>>
    >>>>>> time( &cur_time );
    >>>>>> localtime_r( &cur_time, my_time );
    >>>>>> ...
    >>>>>>
    >>>>>> segfaults on the `localtime_r` call.
    >>>>>
    >>>>> Bad call. From N869:
    >>>>>
    >>>> Why?
    >>>
    >>> Probably due to him jumping the gun again and not seeing the _r
    >>> part.

    >>
    >> True. However I don't recall that localtime_r code was shown.

    >
    > It's in the article you quoted. And there it is again, for your
    > convenience. Just look up ^^^

    No, it's not. The call to localtime_r is shown, but not it's code.

    Bye, Jojo
     
    Joachim Schmitz, Jan 30, 2008
    #11
  12. JLeidel

    Randy Howard Guest

    On Wed, 30 Jan 2008 08:41:06 -0600, Joachim Schmitz wrote
    (in article <fnq2a4$avh$>):

    > Randy Howard wrote:
    >> On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote
    >> (in article <>):
    >>
    >>> Randy Howard wrote:
    >>>> Ian Collins wrote
    >>>>> CBFalconer wrote:
    >>>>>> JLeidel wrote:
    >>>>>>>
    >>>>>>> time( &cur_time );
    >>>>>>> localtime_r( &cur_time, my_time );
    >>>>>>> ...
    >>>>>>>
    >>>>>>> segfaults on the `localtime_r` call.
    >>>>>>
    >>>>>> Bad call. From N869:
    >>>>>>
    >>>>> Why?
    >>>>
    >>>> Probably due to him jumping the gun again and not seeing the _r
    >>>> part.
    >>>
    >>> True. However I don't recall that localtime_r code was shown.

    >>
    >> It's in the article you quoted. And there it is again, for your
    >> convenience. Just look up ^^^

    > No, it's not. The call to localtime_r is shown, but not it's code.


    *sigh*

    It was code /using/ localtime_r. If you want to see what the
    implementation for that looks like, fine, but that has nothing to do
    with what happened earlier in this thread.


    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
     
    Randy Howard, Jan 30, 2008
    #12
  13. Randy Howard wrote:
    > On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote


    >> True. However I don't recall that localtime_r code was shown.

    >
    > It's in the article you quoted. And there it is again, for your
    > convenience. Just look up ^^^


    It's time you learned to read. Nowhere did CDFalconer suggest there
    were no references to localtime_r. He said that he did not recall that
    the localtime_r _code_ was shown. Since localtime_r is not part of
    standard C, any questions about it require that its _code_ be shown or
    we can't known what it is or does. Worse, there is not even a prototype
    shown, so we can't even know what the arguments ought to be.
     
    Martin Ambuhl, Jan 30, 2008
    #13
  14. Martin Ambuhl <> writes:
    > Randy Howard wrote:
    >> On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote
    >>> True. However I don't recall that localtime_r code was shown.

    >>
    >> It's in the article you quoted. And there it is again, for your
    >> convenience. Just look up ^^^

    >
    > It's time you learned to read. Nowhere did CDFalconer suggest there
    > were no references to localtime_r. He said that he did not recall
    > that the localtime_r _code_ was shown. Since localtime_r is not part
    > of standard C, any questions about it require that its _code_ be shown
    > or we can't known what it is or does. Worse, there is not even a
    > prototype shown, so we can't even know what the arguments ought to be.


    True, but it's safe to assume that the value of an uninitialized
    variable is not a valid argument. In the call shown in the posted
    code fragment, one of the arguments was an apparently uninitalized
    variable; just evaluating it invokes UB even before the call. (In
    practice, bad things are likely to happen inside localtime_r() when it
    tries to use the parameter.)

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 30, 2008
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rodney Edmondson
    Replies:
    11
    Views:
    656
    Jeremy
    Dec 9, 2003
  2. flamesrock
    Replies:
    8
    Views:
    473
    Hendrik van Rooyen
    Nov 24, 2006
  3. mk
    Replies:
    4
    Views:
    312
  4. Virchanza
    Replies:
    8
    Views:
    1,108
    Nobody
    Apr 6, 2011
  5. Replies:
    1
    Views:
    116
    Joost Diepenmaat
    Apr 13, 2008
Loading...

Share This Page