Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
* 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
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. I thought it may be something such, but maybe the error message could be made something more explicit ? I guess the assertion is to check if more than one version of localtime_r is working then ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
* 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. 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.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
* Sven Luther: 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. timer_gettime is async-signal-safe according to POSIX. Perhaps gettimeofday is as well, as a GNU extension. Another option is to spawn a separate thread which handles all the signals. Then you aren't restricted to the small set of async-signal-safe functions (and you can use third-party libraries as well). Most non-C programming environments use this approach. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
