Date: Fri, 19 Sep 1997 12:59:33 +0800 From: Peter Wemm <peter@spinner.dialix.com.au> 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 Message-ID: <199709190459.MAA07378@spinner.dialix.com.au> In-Reply-To: Your message of "18 Sep 1997 23:41:00 EDT." <199709190401.VAA06335@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709190459.MAA07378>