Bugzilla Bug 198448

I have a simple program dynamically linked agains pthread.

When i try to set a breakpoint in a child thread created with pthread_create i
get

Program terminated with signal SIGTRAP, Trace/breakpoint trap.

Doenst happen on other non-gentoo distributions
Tried on 2 gentoo distributions and happens...there are already 2 bugs in gdb
bugzilla related to this

It looks like gdb doesnt stop on its own breakpoints if these are sent in child
pthreads

I have latest kernel

gcc (GCC) 4.1.2 (Gentoo 4.1.2)

---------------
GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Compiled by GNU CC version 4.1.2 (Gentoo 4.1.2).
Compiled on a Linux >>2.6.22-gentoo-r8<< system on 2007-11-06.
Available extensions:
        C stubs add-on version 2.1.2
        crypt add-on version 2.1 by Michael Glad and others
        Gentoo patchset 1.1
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc core.
        BIND-8.2.3-T5B

Reproducible: Always

Steps to Reproduce:
1.gcc -g -o pthreadtest pthreadtest.c -lpthreads
2../pthreadtest  &
3.gdb -p `pgrep pthreadtest`
4.b 12
5. continue

wait a little...when SIGTRAP is issued the message in summary is displayed and
program is crushed



Expected Results:  
Stop at breakpoint and remain theere

Created an attachment (id=135487) [details]
test program for bug

seems to be related to the compilation of glibc 2.6.1

also happens if using intel debugger so its not a gcc problem

vanilla compilation of glibc 2.6.1 fixes the problem so its about the gentoo
patches

vanilla compilation fixes part of the problem

I realized now if i attach to the pthread process the problem still happens

gdb -p `pgrep pthreadtest`

Would you check the patch I posted at bug 196031, I think this is actually a
duplicate of that (and it may fix your problem ;). With it I get a proper
break.

Yes...avoid stripping of libpthread and libpthread_db and problem is gone

*** This bug has been marked as a duplicate of bug 196031 ***