Message-ID: <4399D1B0.8030906@aventail.com>
Date: Fri, 09 Dec 2005 10:49:20 -0800
From: Steve Work <swork@aventail.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: [REPOST] Multi-thread corefiles broken since April
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2581
Lines: 70

Q: When did *all* multi-thread userspace coredumps break?
A: 2.6.12-rc3, specifically April 16; and they're still broken (really!) 
  Config does not appear to matter.  Not a race: highly reproduceable, 
see below.

-------- Original Message --------
Subject: Multi-thread corefiles broken since April
Date: Wed, 07 Dec 2005 22:52:52 -0800
From: Steve Work <swork@aventail.com>
To: linux-kernel@vger.kernel.org

Coredumps from programs with more than one thread show garbage
information for all threads except the primary.  The problem was
introduced with:

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5df240826c90afdc7956f55a004ea6b702df9203

on Apr 16 ("fix crash in entry.S restore_all") and is still present in
current builds.

"kill -SEGV" this program and "info threads" the resulting corefile to
see the problem:

#include <pthread.h>
static void* thread_sleep(void* x) { while (1) sleep(30); }
int main(int c, char** v) {
     const static int tcount = 5;
     pthread_t thr[tcount];
     int i;
     for (i=0; i<tcount; ++i)
         pthread_create(&thr[i], NULL, thread_sleep, NULL);
     while (1)
         sleep(30);
     return 0;
}

(gdb) info threads
   7 process 18138  0x00000246 in ?? ()
   6 process 18139  0x00000246 in ?? ()
   5 process 18140  0x00000246 in ?? ()
   4 process 18141  0x00000246 in ?? ()
   3 process 18142  0x00000246 in ?? ()
   2 process 18143  0x00000246 in ?? ()
* 1 process 18137  0xb7e69db6 in nanosleep () from /lib/tls/libc.so.6
(gdb)

All these threads should show a legitimate location (the same spot in
nanosleep) and do on kernels prior to the commit named above.  (Notice
one too many threads listed here also -- is this a related problem?)

Commenting out this line (in asm/i386/kernel/process.c:copy_thread)
fixes the corefiles:

   childregs = (struct pt_regs *) ((unsigned long) childregs - 8);

but presumably re-introduces the crash the original patch was intended
to fix.  Should this line be conditioned somehow?  Or do the corefile
write routines need to know about this adjusted offset?

Steve Work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/