From owner-freebsd-bugs  Thu Sep 18 22:00:15 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA10417
          for bugs-outgoing; Thu, 18 Sep 1997 22:00:15 -0700 (PDT)
Received: from spinner.dialix.com.au (spinner.dialix.com.au [202.12.86.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA10314;
          Thu, 18 Sep 1997 21:59:55 -0700 (PDT)
Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1])
          by spinner.dialix.com.au with ESMTP id MAA07378;
          Fri, 19 Sep 1997 12:59:34 +0800 (WST)
Message-Id: <199709190459.MAA07378@spinner.dialix.com.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Andrew Atrens" <atrens@nortel.ca>
cc: hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk,
        freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "18 Sep 1997 23:41:00 EDT."
             <199709190401.VAA06335@hub.freebsd.org> 
Date: Fri, 19 Sep 1997 12:59:33 +0800
From: Peter Wemm <peter@spinner.dialix.com.au>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

"Andrew Atrens" wrote:
> 
> Hi Folks,
> 
> By coincidence I *may* have seen a bug similar to Graham's last night...
> I'm using 3.0 current ( circa. Aug 08 ).
> 
> I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a
> largely C++ interface for gdb and others. Unfortunately, when I tried to
> run it, it gobbled memory until it choked. I tried a second time, this
> time killing it with CTRL-C and observed:
> 
> ^Cddd in malloc(): warning: recursive call.
> Virtual memory exceeded in `new'
> 
> After reading Graham's thread I relinked it against libgnumalloc, and low
> and behold it works like a charm !
> 
> Does this point to an incompatibility problem between phkmalloc and g++
> compiled code ?

Hmm, this particular thing sounds like a signal recursion problem..

If a malloc() instance is interrupted in the middle of execution and a
signal is taken, and that signal again calls malloc (eg: via new), the
state of the malloc arena is 'indeterminate'.

Perhaps malloc is doing something that can cause a signal?  or perhaps ddd
has a fast timer that calls malloc (or new) that can interrupt other malloc
calls?  Perhaps malloc() could/should block SIGALRM while executing it's 
non-reentrant parts?

> Just a thought,
> 
> Andrew.
> 

Cheers,
-Peter