From owner-freebsd-hackers Sun Aug 12 6:46: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from neptune.he.net (neptune.he.net [216.218.166.2]) by hub.freebsd.org (Postfix) with ESMTP id 5085D37B406; Sun, 12 Aug 2001 06:45:55 -0700 (PDT) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com ([210.52.155.75] (may be forged)) by neptune.he.net (8.8.6/8.8.2) with ESMTP id GAA20181; Sun, 12 Aug 2001 06:45:55 -0700 Received: (from robinson@localhost) by netrinsics.com (8.11.2/8.11.1) id f7CDk8602811; Sun, 12 Aug 2001 21:46:08 +0800 (+0800) (envelope-from robinson) Date: Sun, 12 Aug 2001 21:46:08 +0800 From: Michael Robinson To: Daniel Eischen Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: _sigprocmask in malloc.c causes full file table? Message-ID: <20010812214608.A2701@elephant.netrinsics.com> References: <20010812152655.A1569@elephant.netrinsics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Sun, Aug 12, 2001 at 08:52:20AM -0400 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 Doesn't *anybody* RTFPR? This is the fifth respondent in a row to have comprehensively missed the point. On Sun, Aug 12, 2001 at 08:52:20AM -0400, Daniel Eischen wrote: > On Sun, 12 Aug 2001, Michael Robinson wrote: > > Thank you for that very helpful bit of information, but I already knew that. > > > > What I do not know is how it is possible for a null _sigprocmask call > > (a SIG_BLOCK call with no mask bits set) in libc/stdlib/malloc.c to cause a > > kernel error, "file: table is full", in libc_r/uthread/uthread_init.c. > > This is the first time that I saw libc_r was involved. Actually, POSIX > (1003.1, 1996) says this about sigprocmask: > > "The use of the sigprocmask() function is unspecified in a > multithreaded process." > > FreeBSD behaviour of sigprocmask() is the same as Solaris. sigprocmask() > changes the mask of the calling thread, not the process. In other words, > it is identical to pthread_sigmask(). > > If it is being used to block signals for threads other than the calling > thread, it won't work. Allow me to quote: "a null _sigprocmask call (a SIG_BLOCK call with no mask bits set)" We can demonstrate that this is documented to have the same effect on all threads. I.e., none whatsoever. The point is that not only does this putative no-op have an op, the op is in fact an entirely unrelated error in an entirely unrelated location: pipe creation fails with a system "file: table is full" error. I'm not a famous FreeBSD kernel hacker, but if I were, I might want to ascertain that this was not due to a previously hidden pathological code path. For convenience, I am including the original report below in its entirety. -Michael P.S. I'll gladly provide diff's for anyone who may want to try to reproduce this. It's 100% trivially reproducible on my system (-CURRENT as of Jan. 31). --- 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. Following the example of, e.g., stdlib/system.c, I tried blocking the usual suspects (SIGIO, SIGWINCH, etc.), as follows: void free(void *ptr) { sigset_t old_procmask; THREAD_LOCK(); _sigprocmask(SIG_BLOCK, &malloc_procmask, &old_procmask); malloc_func = " in free():"; if (malloc_active++) { wrtwarning("recursive call.\n"); } else { ifree(ptr); UTRACE(ptr, 0, 0); } malloc_active--; _sigprocmask(SIG_SETMASK, &old_procmask, NULL); THREAD_UNLOCK(); return; } That worked for the general case, but it broke mozilla in an interesting way; mozilla would fail to create a kernel pipe in uthread_init.c, and I would get a system error: Aug 11 07:33:25 elephant /boot/kernel/kernel: file: table is full Aug 11 07:33:25 elephant /boot/kernel/kernel: pid 358 (mozilla-bin), uid 1000 : exited on signal 6 (core dumped) I then changed the initialization of malloc_procmask so that it contained no signals whatsoever, and the exact same thing happened. I then commented out all calls to sigprocmask, and everything returned to normal. Am I doing something completely boneheaded, or is this an undocumented subtle interaction? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message