Date: Fri, 19 Sep 1997 07:53:53 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Wemm <peter@spinner.dialix.com.au> Cc: "Andrew Atrens" <atrens@nortel.ca>, hackers@freebsd.org, gram@cdsec.com, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free Message-ID: <12447.874648433@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 19 Sep 1997 12:59:33 %2B0800." <199709190459.MAA07378@spinner.dialix.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199709190459.MAA07378@spinner.dialix.com.au>, Peter Wemm writes: >> ^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? The solution here would be to block signals around malloc/free. This would be rather expensive to do, performance wise, and thus have not been done. It is the responsibility of the application code anyway... If somebody writes the patch to malloc to do this under a option, I'll review and commit, but I don't have the time to do it myself right now. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12447.874648433>