Date: Sun, 12 Aug 2001 21:46:08 +0800 From: Michael Robinson <robinson@netrinsics.com> To: Daniel Eischen <eischen@vigrid.com> Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: _sigprocmask in malloc.c causes full file table? Message-ID: <20010812214608.A2701@elephant.netrinsics.com> In-Reply-To: <Pine.SUN.3.91.1010812083915.15273A-100000@pcnet1.pcnet.com>; from eischen@vigrid.com on Sun, Aug 12, 2001 at 08:52:20AM -0400 References: <20010812152655.A1569@elephant.netrinsics.com> <Pine.SUN.3.91.1010812083915.15273A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010812214608.A2701>