bug-glibc
[Top][All Lists]
Advanced

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

Re: Is malloc signal-"tolerant"?


From: Stefan Hoffmeister
Subject: Re: Is malloc signal-"tolerant"?
Date: Sun, 23 Dec 2001 14:24:43 +0100

: On 23 Dec 2001 09:56:52 -0000, Wolfram Gloger wrote:

>> I am not certain whether I understand this comment. Asynchronous signals
>> will interrupt any user code, be it a spinlock or not?
>
>Sure.  But the spinlock provides an atomic, signal-safe means of
>deciding whether a malloc arena is in use or not.

Oh, now I get the point of that exercise!

>What _still_ won't work is, if your example was modified to eg. later
>free() a pointer that was allocated _before_ the signal interruption
>-- that would hang.  I.e. once you have interrupted malloc/free and
>longjmp()ed somewhere, you can only alloc/free _new_ memory.

IOW, the idea behind this is to allow memory operations on an error path
that is strictly separate from a "useful work path" - and the error path
will never merge with the work path again? "Merging", except in most
trivial code, would imply that pointers to "old" memory are still around
and be "freeable". The solution could be to drop all pointers, but that
would leak really, really massively for applications which make heavy
use of dynamically allocated memory. On top of that, "dropping all
pointers" might be very difficult or even not be feasible in the
presence of reference-counted data structures.

In a sense this means that the error path (entered from a longjmp() out
of a signal handler) will have to invariably lead to program
termination?

TIA!
Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]