Re: Realloc is blocking execution
Mike Hommey <mh@glandium.org> writes:
> On Fri, Oct 16, 2009 at 12:02:26PM +0200, Bernhard R. Link wrote:
>> * Mats Erik Andersson <mats.andersson@gisladisker.se> [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 debian-mentors-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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
Reply to: