From: Adrian Bunk <bunk@stusta.de>
To: Steve Work <swork@aventail.com>, Stas Sergeev <stsp@aknet.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Multi-thread corefiles broken since April
Date: Sat, 31 Dec 2005 15:28:51 +0100 [thread overview]
Message-ID: <20051231142851.GH3811@stusta.de> (raw)
In-Reply-To: <4397D844.8060903@aventail.com>
Hi Steve,
please open a bug at http://bugzilla.kernel.org/ for this issue so that
it doesn't get lost.
@Stas:
It was your patch that broke it, can you look into it?
TIA
Adrian
On Wed, Dec 07, 2005 at 10:52:52PM -0800, Steve Work wrote:
> 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
next prev parent reply other threads:[~2005-12-31 14:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-08 6:52 Multi-thread corefiles broken since April Steve Work
2005-12-11 0:44 ` Andrew Morton
2005-12-31 14:28 ` Adrian Bunk [this message]
2006-01-01 1:18 ` Stas Sergeev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051231142851.GH3811@stusta.de \
--to=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stsp@aknet.ru \
--cc=swork@aventail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox