måndag den 19 oktober 2009 klockan 11:59 skrev Goswin von Brederlow detta: > Mike Hommey <[email protected]> writes: > > > On Fri, Oct 16, 2009 at 12:02:26PM +0200, Bernhard R. Link wrote: > >> * Mats Erik Andersson <[email protected]> [091016 11:55]: > >> > 4. The main process WM receives SIGHUP, and enters a signal handler. > >> > The signal handler uses two calls: free_menuitems(), get_menuitems(). > >> > >> If those calls call malloc or free or anything else this might be the > >> problem. Memory allocation functions are not reentrant and due to > >> threading support are easily blocking when used this way. > > > > Sadly, the manual page for these functions under linux doesn't seem to > > say anything about that, contrary to other unices man pages. Maybe this > > should be filed as a wishlist bug. > > > > Mike > > > > > > -- > > To UNSUBSCRIBE, email to [email protected] > > with a subject of "unsubscribe". Trouble? Contact > > [email protected] > > man 7 signal > > Async-signal-safe functions > A signal handling routine established by sigaction(2) or > signal(2) must be very careful, since processing elsewhere may > be interrupted at some arbitrary point in the execution of the > program. POSIX has the concept of "safe function". If a > signal interrupts the execution of an unsafe function, and > handler calls an unsafe function, then the behavior of the > program is undefined. > > POSIX.1-2004 (also known as POSIX.1-2001 Technical Corrigendum > 2) requires an implementation to guarantee that the following > functions can be safely called inside a signal handler: > > <long list follow> > > The list certainly does not contain malloc() or realloc(). So what you > see is that the undefined behaviour changed from luckily working to > blocking. The code does somthing wrong and now it bites you in the ass. :) > > I doubt there is anything to fix this other than fixing your code to > get out of the signal handler as fast as possible and do the real work > outside. > > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] >
Yes, I have already suggested this to the upstream author. Thanks, for the pointer. I just tried to compile and run the same source tar-ball an a new system with Debian testing. I tried to keep the number of packages down when doing a dist-upgrade from Lenny, but the outcome was the sysrq-RIESUB both times! And I did not even invoke any signal, so possibly the installed system was incomplete to begin with. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
