From owner-freebsd-bugs Thu Sep 18 23:06:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA15436 for bugs-outgoing; Thu, 18 Sep 1997 23:06:58 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA15409; Thu, 18 Sep 1997 23:06:49 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA01685; Thu, 18 Sep 1997 23:06:17 -0700 (PDT) Message-ID: <19970918230616.02227@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 23:06:16 -0700 From: John-Mark Gurney To: Peter Wemm Cc: Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709190401.VAA06335@hub.freebsd.org> <199709190459.MAA07378@spinner.dialix.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au>; from Peter Wemm on Fri, Sep 19, 1997 at 12:59:33PM +0800 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Peter Wemm scribbled this message on Sep 19: > "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? I thought that you weren't suppose to call routines like these from signal handlers... and from the APUE (page278): "Most functions that are not in Figure 10.3 [Reentrant functions that may be called from a signal handler] are missing because (a) they are known to use static data structures, (b) they call malloc or free, or (c) they are part of the standard I/O library." so any program that makes calles to these functions are VERY broken... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD