Date: Fri, 19 Sep 1997 19:54:38 +1000 From: Bruce Evans <bde@zeta.org.au> To: mike@smith.net.au, phk@critter.freebsd.dk Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org, julian@whistle.com Subject: Re: Bug in malloc/free Message-ID: <199709190954.TAA11275@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>> probably a printf or other stdio function >> >>I *know* this. 8) I'm just trying to find the sucker. The 'ddd' example >>looked like it was spinning in abort(), which doesn't look like it will >>actually come back and call malloc() again. In olden days, >... >Some time ago abort() was changed to that it would call __flush(), >because some standard said so. I still think this is unwise. Standard C says that whether streams are flushed by abort() is implementation-defined. POSIX says that abort() shall have the effects of fclose() if abort() causes process termination, but shall have no effects otherwise. Our implementation doesn't quite confirm to this, since the effects of flushing can be detected: 1. setvbuf() to unbuffered and size 2, then putc() 1 byte, then _exit(). I think it is guaranteed that 0 bytes are written. 2. As in (1), but set up a SIGABRT handler so that abort() doesn't cause termination, and call abort() before _exit(). Flushing in abort() should be safe because abort() is not among the functions that are safe to call from a signal handler :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709190954.TAA11275>