Summary: | Cannot find new threads: generic error | ||
---|---|---|---|
Product: | gdb | Reporter: | Carlo Wood <carlo> |
Component: | threads | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | gbenson, gdb-prs, john.carter, pedro |
Priority: | P3 | ||
Version: | 7.2 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Bug Depends on: | 17629 | ||
Bug Blocks: | |||
Attachments: |
Very short file that "kills gdb".
fix |
Description
Carlo Wood
2008-09-27 17:38:01 UTC
(In reply to comment #0) Identical problem, with plain C code that also uses no threads, but does use dynamic libraries: % gdb xques GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/cgrayce/bin/xques...done. (gdb) run -i 31d_uconvert.xml example-xhtml Starting program: /home/cgrayce/bin/xques -i 31d_uconvert.xml example-xhtml [Thread debugging using libthread_db enabled] Cannot find new threads: generic error ldd `which xques` linux-gate.so.1 => (0x00ce2000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00164000) libz.so.1 => /lib/libz.so.1 (0x0035a000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00642000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x0036f000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00ef2000) /lib/ld-linux.so.2 (0x0091c000) uname -a Linux spock 2.6.32-22-generic #35-Ubuntu SMP Tue Jun 1 14:17:36 UTC 2010 i686 GNU/Linux Created attachment 5756 [details] Very short file that "kills gdb". To compile and demonstrate the bug... gcc -O0 -g -pthread -o kill_gdb kill_gdb.c /usr/bin/gdb ./kill_gdb GNU gdb (GDB) 7.2-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /btrfs/johnc/tmp/kill_gdb...done. (gdb) start Temporary breakpoint 1 at 0x8048367: file kill_gdb.c, line 7. Starting program: /btrfs/johnc/tmp/kill_gdb [Thread debugging using libthread_db enabled] Cannot find new threads: generic error (gdb) If file being debugged uses libpthread AND has an external symbol "stack_used" gdb dies before the debugged program enters "main" with the message... [Thread debugging using libthread_db enabled] Cannot find new threads: generic error In the attached file, for example you change all occurrences of "stack_used" by "tack_used" and recompile and run gdb executes normally. If you leave it as "stack_used", gdb dies with an entirely mystifying error message! Thanks. Environment uname -a Linux parore 2.6.35-28-generic-pae #50-Ubuntu SMP Fri Mar 18 20:43:15 UTC 2011 i686 GNU/Linux /usr/bin/gcc --version gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 Created attachment 5757 [details]
fix
Thanks for the testcase. It makes the problem dead obvious --- GDB is looking up symbols in the globally, instead of on the object thread_db requests. I've attached a proposed fix. My thread_db always passes in a basenamed obj=libpthread.so.0. Not sure that'll always be the case. Anyone know otherwise? Not sure how relevant this is, but there is a function libpthread_name_p defined in solib.c. Yeah, didn't look useful. Fair enough :) The patch breaks thread debugging of threaded static programs. E.g., the gdb.threads/staticthreads test: Breakpoint 3, ps_pglobal_lookup (ph=0xf248f8, obj=0x7ffff5b84541 "libpthread.so.0", name=0x7ffff5b84665 "nptl_version", sym_addr=0x7fffffffd5c8) at ../../src/gdb/proc-service.c:207 207 ALL_OBJFILES (objfile) There's no libpthread.so loaded by this program, so all symbol lookups thread_db tries fail... Any ideas? Is there any reason glibc couldn't move the symbols it wants to check against to the private namespace (nptl_version ==> __nptl_version, etc.)? Filed glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17629 |