malloc's and signals -- a dangerous mixture?

[Steve Summit]

In article <1064 at dinl.mmc.UUCP> noren at dinl.UUCP (Chuck Noren) writes:
>...malloc's are dangerous to use in combination with signal
>handlers.  I can see the potential problem if the malloc
>library uses static storage and an malloc is interrupted with
>another malloc in a signal handler.  Could someone shed some
>light on the subject and possibly provide some rules when
>malloc's are safe (and portable) to use with signals. 

Of the various things you might want to do in a signal handler,
I've found malloc/free to be among the least reliable.  Setting
flags is fairly certain to work; you can usually get away with
a printf; but a malloc or free is almost guaranteed to fail.

malloc is complicated and does a lot of work (so its window of
vulnerability, during which it could be interrupted by a signal,
is large) and it maintains interconnected data structures (which
can be invalidated if e.g. mutually dependent pointers are not
updated in synchrony, which is a problem even in the absence of
truly static data).

Traditional malloc implementations are notoriously sensitive to
any kind of corruption -- merely overwriting a malloc'ed buffer
by one byte (perhaps the most common error) usually throws them
into a tizzy.  (This might be beneficial, for bug-catching
purposes, if the symptoms of overwriting didn't manifest
themselves 30 malloc's later.)

Many people have researched better malloc implementations,
usually for speed or better space utilization.  Has anyone ever
tried to make a more robust implementation (this is essentially a
"core war"-type problem), similar to the file system
modifications Berkeley occasionally makes to lessen the disks'
vulnerability to machine crashes in the middle of writes and to
make fsck's job easier?

                                            Steve Summit
                                            scs at adam.pika.mit.edu