Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed

[sven@powerlinux.fr (Sven Luther)]

On Thu, Apr 05, 2007 at 01:35:22PM +0200, Florian Weimer wrote:
> * Sven Luther:
> 
> > On Thu, Apr 05, 2007 at 08:46:08AM +0200, Florian Weimer wrote:
> >> * Sven Luther:
> >> 
> >> > As said, i see this on both an x86 box and my powerbook, but the complete code
> >> > is more involved, having a pselect, as well as a SIGALRM handler, which both
> >> > trigger the localtime_r, as well as a postgresql access and files access.
> >> 
> >> localtime_r is not async-signal-safe, so this could be a bug in your
> >> program.
> >
> > Ok, i will give a try of using just localtime.
> 
> localtime is not async-signal-safe, either.  A full list of such
> functions is contained in the POSIX standard and probably the GNU libc
> documentation as well.

The documentation which was stripped from debian because of GFDL issues, right
? 
> > I thought it may be something such, but maybe the error message
> > could be made something more explicit ?
> 
> You are asking for a general detection mechanism for race conditions,
> which is not really feasible for production code.
> 
> > I guess the assertion is to check if more than one version of
> > localtime_r is working then ?
> 
> If you invoke a function which is not async-signal-safe from a signal
> handler, all bets are off.  That sanity check doesn't check for the
> race condition, it merely catches the inconsistency caused by it (from
> time to time).
> 
> (All this assumes that your bug is caused by improper use of a signal
> handler.  Keep in mind that this is not necessarily the case.  But you
> should fix that aspect of your code nevertheless.)

Yes, i use localtime / getoftime / time from the signal handler, yes, i guess
that is causing the problem i m seeing. Need to find another way to find the
time from a handler.

maybe using the timer_create thingy, but it is also undocumented.

Friendly,

Sven Luther