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

In article <7dd592b3-f9f1-4399-9e79-55118153b82c@s12g2000prg.googlegroups.com>,
JLeidel <john.leidel@gmail.com> 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

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 | fogobum@comcast.net
Always code as if the person who ends up maintaining your code will be a
violent psychopath who knows where you live.

JLeidel <john.leidel@gmail.com> 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) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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 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.

On Mon, 28 Jan 2008 00:53:32 -0600, Ian Collins wrote
(in article <605cfbF1ohsu3U5@mid.individual.net>):

> 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

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.

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

On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote
(in article <479E575B.AD0D24B2@yahoo.com>):

> 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 wrote:
> On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote
> (in article <479E575B.AD0D24B2@yahoo.com>):
>
>> 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

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

> Randy Howard wrote:
>> On Mon, 28 Jan 2008 16:29:47 -0600, CBFalconer wrote
>> (in article <479E575B.AD0D24B2@yahoo.com>):
>>
>>> 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 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 <mambuhl@earthlink.net> 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) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"