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 attachment 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 ***
