From owner-freebsd-hackers Thu Sep 18 23:28:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA16915 for hackers-outgoing; Thu, 18 Sep 1997 23:28:34 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16910; Thu, 18 Sep 1997 23:28:30 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id PAA03644; Fri, 19 Sep 1997 15:58:14 +0930 (CST) Message-ID: <19970919155813.53901@lemis.com> Date: Fri, 19 Sep 1997 15:58:13 +0930 From: Greg Lehey 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.81e In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au>; from Peter Wemm on Fri, Sep 19, 1997 at 12:59:33PM +0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 12:59:33PM +0800, Peter Wemm wrote: > "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'. Even more insidious are library routines which could call malloc(). To quote PUS: By definition, signals interrupt the normal flow of program execution. This can cause problems if they call a function that has already been invoked, and which has saved some local state. The function needs to be written specially to avoid such problems--it should block either all signals during execution, or, preferably, it should be written reentrantly. Either solution is difficult, and typically system libraries do not support this kind of reentrancy. On the other hand, there's not much you can do without calling some library routine. POSIX.1 defines "safe" routines that you can call from a signal handler. They are: _exit access alarm cfgetispeed cfgetospeed cfsetispeed cfsetospeed chdir chmod chown close creat dup dup2 execle execve fcntl fork fstat getegid geteuid getgid getgroups getpgrp getpid getppid getuid kill link lseek mkdir mkfifo open pathconf pause pipe read rename rmdir setgid setpgid setsid setuid sigaction sigaddset sigdelset sigemptyset sigfillset sigismember sigpending sigprocmask sigsuspend sleep stat sysconf tcdrain tcflow tcflush tcgetattr tcgetpgrp tcsendbreak tcsetattr tcsetpgrp time times umask uname unlink utime wait waitpid write In addition, System V.4 allows abort, exit, longjmp, and signal. Should we produce some such guidelines? > 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? Greg