[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Realloc is blocking execution



måndag den 19 oktober 2009 klockan 11:59 skrev Goswin von Brederlow detta:
> 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
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

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.


Reply to: