From owner-freebsd-hackers Sat Aug 11 12: 5:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 2763237B409; Sat, 11 Aug 2001 12:05:45 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.88.Dial1.SanJose1.Level3.net [209.245.135.88]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA13417; Sat, 11 Aug 2001 12:05:43 -0700 (PDT) Message-ID: <3B75822F.E84799BD@mindspring.com> Date: Sat, 11 Aug 2001 12:06:23 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Robinson Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? References: <200108110115.f7B1F4100321@netrinsics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Robinson wrote: > > I'm currently trying to deal with the problem where malloc/free in a > signal handler will crash (in my case, the X window server) if a signal > arrives during malloc or free. The manual pages suck, since this should be under signal(3), not as a reference to sigaction(2), but... man 2 sigaction You can not allocate or free in signal handlers because malloc(3) and free(3) use brk(2) and sbrk(2), which are system calls that can't be used in a signal handler, since they are missing from the list of permitted function. Signals are pretty brain damaged anyway: the correct way to deal with them is to set a flag, and then handle them in the main event loop by checking the flag. NB: ANSI C requires you to mark this flag as "volatile", even though all externally referenced variables from signal handlers should be implicitly volatile, so that it doesn't optimize it into a register on you, and make your code not work. It's really not that hard to clean up the code... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message