noren@dinl.uucp (Charles Noren) (07/10/89)
While reading the C standards group I came across the comment
that 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.
Information specific to Sun 3 with SunOS 4.0 along with issues
dealing with other systems in general is desired.
Thanks in advance.
--
Chuck Noren
NET: ncar!dinl!noren
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
Denver, CO 80201-1260
Phone: (303) 971-7930gwyn@smoke.BRL.MIL (Doug Gwyn) (07/11/89)
In article <1064@dinl.mmc.UUCP> noren@dinl.UUCP (Chuck Noren) writes: >... Could someone shed some light on the subject and possibly provide >some rules when malloc's are safe (and portable) to use with signals. In general, for portable applications, signal handlers are unsafe for almost ANY use. If you know for sure that a signal either will not recur while processing an instance of it or will not have the handler reset to SIG_DFL during handling, then it is safe to set an shared atomic flag from within the signal handler and resume where interrupted. The proposed C standard specifies a small number of other things that are supposed to be safe for signal handlers to do (assuming a standard- conforming implementation), but I don't know how to implement some of them reliably in typical UNIX environments (for example). I argued in X3J11 meetings against guaranteeing anything at all for signal handlers. POSIX (or similar) "reliable signals" permit more things to be done safely within signal handlers; however, it is still not safe in general to invoke the majority of C library routines from a signal handler. The cost of making them safely reentrant will probably preclude most implementors from doing so. Vendors of so-called "real time" systems may decide to do so, but I wouldn't expect others to. The "signal" mechanism was not really intended to support concurrent programming; it was meant to provide a way to handle abnormal conditions short of simply aborting the process. Trying to do other things with it will eventually get you in trouble.
scs@adam.pika.mit.edu (Steve Summit) (07/11/89)
In article <1064@dinl.mmc.UUCP> noren@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@adam.pika.mit.edu
kpv@ulysses.homer.nj.att.com (Phong Vo[drew]) (07/11/89)
In article <1064@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes: > 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. As a rule, never call malloc/realloc/free from a signal handler. At best, you sometimes lose memory. At worst, the arena can be corrupted causing unexpected program behaviors. For the same reasons, take extra care to make sure that you are not in a malloc family call if your handler uses longjmp.
kpv@ulysses.homer.nj.att.com (Phong Vo[drew]) (07/11/89)
In article <12571@bloom-beacon.MIT.EDU>, scs@adam.pika.mit.edu (Steve Summit) writes: > 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 Robust malloc sounds like a good example of an oxymoron. My one great contribution to fault-tolerant computing that may help some programs to limp a little longer is to always double the size of the malloc request. Quiz: what famous UNIX os provides a malloc with almost that feature:-)? On a more serious vein, there are simple ways to add trace information to malloc space and periodically check to see if the arena has been corrupted. Doing this, of course, will make the program runs slooooow.
henry@utzoo.uucp (Henry Spencer) (07/11/89)
In article <12571@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >Many people have researched better malloc implementations, >usually for speed or better space utilization. Has anyone ever >tried to make a more robust implementation... There was a paper at a Usenix a few years ago -- I think it was Portland -- comparing mallocs by several criteria, including robustness. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu