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]
