I wrote a REAL simple threaded program to test out a bug report for my malloc
debugger, and I get the following behavior from gdb 5.0:

> gcc thread.c -g3 -o thread -pthread
> gdb thread

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu"...
(gdb) run
Starting program: /home/mikepery/programming/njamd/tests/thread 
[New Thread 1024 (runnable)]
[New Thread 2049 (runnable)]
[New Thread 1026 (runnable)]
yo

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1026 (runnable)]
0x0 in ?? ()
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0 in ?? ()
(gdb) cont
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Here's the source:

#include <stdio.h>
#include <pthread.h>

void tmp(void *a)
{   
    write(1, "yo\n", 3);
}

int main(void)
{   
    pthread_t thr;
    pthread_create(&thr, NULL, tmp, NULL);
    write(1, "yo2\n", 4);
    return 0;
}

gdb 4.18 has no problems with this at all. (Yes, there is obviously a race
condition here, but that was part of my test). In 5.0, it happens with or
without the write race. Sometimes the process just disapears instead of gdb
claiming segfaults also. I've also seen SIGILL's when I use my malloc debugger
with this threaded program. (http://fscked.org/proj/njamd.shtml) 

I'm using Linux 2.2.15 w/ glibc 2.1.3 and egcs 1.1.2 on a K6-2 (Redhat 6.2 
based sys).

Reply via email to