From owner-freebsd-bugs  Fri Sep 19 03:59:46 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA03449
          for bugs-outgoing; Fri, 19 Sep 1997 03:59:46 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03427;
          Fri, 19 Sep 1997 03:59:36 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id MAA13266;
	Fri, 19 Sep 1997 12:58:34 +0200 (CEST)
To: Bruce Evans <bde@zeta.org.au>
cc: mike@smith.net.au, atrens@nortel.ca, freebsd-bugs@freebsd.org,
        gram@cdsec.com, hackers@freebsd.org, julian@whistle.com
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 19:54:38 +1000."
             <199709190954.TAA11275@godzilla.zeta.org.au> 
Date: Fri, 19 Sep 1997 12:58:34 +0200
Message-ID: <13264.874666714@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709190954.TAA11275@godzilla.zeta.org.au>, Bruce Evans writes:
>>>> 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 :-).

Bummer.

So what should I do in malloc when I realize that continuing doesn't
make sense ?

	kill (diesig, getpid()); ?
	for which value of diesig ?


--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."