From owner-freebsd-bugs  Fri Sep 19 02:57:19 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA00318
          for bugs-outgoing; Fri, 19 Sep 1997 02:57:19 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00280;
          Fri, 19 Sep 1997 02:57:10 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA11275; Fri, 19 Sep 1997 19:54:38 +1000
Date: Fri, 19 Sep 1997 19:54:38 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199709190954.TAA11275@godzilla.zeta.org.au>
To: mike@smith.net.au, phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com,
        hackers@freebsd.org, julian@whistle.com
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>> 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