Re: Coredumps and pthreads on Linux w/glibc?

["George T. Talbot" <george at moberg dot com>]

Kaz Kylheku wrote:
> 
> On Tue, 4 Apr 2000, George T. Talbot wrote:
> 
> > Date: Tue, 04 Apr 2000 14:45:40 -0400
> > From: George T. Talbot <george@moberg.com>
> > To: libc-alpha@sourceware.cygnus.com
> > Subject: Coredumps and pthreads on Linux w/glibc?
> >
> > I'm running glibc 2.1.3 on x86 Linux (Kernel 2.2.14 SMP).  Can anyone tell me
> > why this program will not dump core when it segfaults?  I've set ulimit -c
> > unlimited, and if I comment-out pthread_create(), the program will dump core.
> 
> The ELF coredump logic in the kernel prevents this. What happens is that
> the kernel checks the reference count on the memory map of the thread.
> It only generates a core dump if the reference count is 1.
> 
> Thus in order to get a core dump from a LinuxThreads application, a thread
> which received the core-generating signal must pass through the core dump
> function after all other threads have released their memory maps.
> 
> So basically, whether you get a core dump or not is the result of a lottery.
> 
> You can patch your kernel to defeat this check.

After patching the kernel to dump every corefile into a file named "core.###"
(###=pid #), I was successfully able to find my bug.

Shame this isn't already part of the POSIX standard.  Does the Linux kernel
know whether a particular process is a thread or not?  If it does, I'd be
willing to extend (and release) my patch to do the following:

	Add some /proc entry (or something like that) with a default value of 0.
	If the entry is 0, then continue the existing behaviour.
	If the entry is 1, then coredump threads, but retain the existing
	behaviour for programs which use shared memory but aren't multithreaded.
	If the entry is 2, then coredump everything, shared memory or not.

Anyhow, I've been trying to fix this bug for about 3 solid weeks now.

Thank you.  Now my boss probably won't fire me. ;^)

--
George T. Talbot
<george at moberg dot com>