lkml.org 
[lkml]   [2005]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Multi-thread corefiles broken since April
    Steve Work <swork@aventail.com> 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.

    Thanks for working that out.

    > "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?
    >

    Yes, I guess fixing up the core output would be the way to fix it.
    -
    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/

    \
     
     \ /
      Last update: 2005-12-11 01:50    [W:0.024 / U:30.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site