Date: Fri, 19 Sep 1997 15:58:13 +0930 From: Greg Lehey <grog@lemis.com> To: Peter Wemm <peter@spinner.dialix.com.au> Cc: Andrew Atrens <atrens@nortel.ca>, hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free Message-ID: <19970919155813.53901@lemis.com> In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au>; from Peter Wemm on Fri, Sep 19, 1997 at 12:59:33PM %2B0800 References: <199709190401.VAA06335@hub.freebsd.org> <199709190459.MAA07378@spinner.dialix.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970919155813.53901>