|Summary:||Cannot find new threads: generic error|
|Product:||gdb||Reporter:||Carlo Wood <carlo>|
|Component:||threads||Assignee:||Not yet assigned to anyone <unassigned>|
|Severity:||normal||CC:||gbenson, gdb-prs, john.carter, palves|
|Bug Depends on:||17629|
Very short file that "kills gdb".
Description Carlo Wood 2008-09-27 17:38:01 UTC
[Converted from Gnats 2530] gdb stopped working, I can't recall why -- must have been some update of the operating system. What happens when I try to debug my C++ application is this: hikaru:~/projects/cwchessboard/cwchessboard-objdir>gdb ./tstpgnread GNU gdb 6.8-debian Copyright (C) 2008 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 "x86_64-linux-gnu"... (gdb) r Starting program: /home/carlo/projects/cwchessboard/cwchessboard-objdir/tstpgnread [Thread debugging using libthread_db enabled] Error while reading shared library symbols: Cannot find new threads: generic error Cannot find new threads: generic error (gdb) This application is NOT using threads. Is this a known problem that I can solve myself or is more information needed? > ldd ./tstpgnread linux-vdso.so.1 => (0x00007fffd61fe000) libgiomm-2.4.so.1 => /usr/local/install/4.3.1/lib/libgiomm-2.4.so.1 (0x00007f28cdbfd000) libgio-2.0.so.0 => /usr/local/install/4.3.1/lib/libgio-2.0.so.0 (0x00007f28cd988000) libglibmm-2.4.so.1 => /usr/local/install/4.3.1/lib/libglibmm-2.4.so.1 (0x00007f28cd701000) libgmodule-2.0.so.0 => /usr/local/install/4.3.1/lib/libgmodule-2.0.so.0 (0x00007f28cd4fe000) libdl.so.2 => /lib/libdl.so.2 (0x00007f28cd2fa000) libgobject-2.0.so.0 => /usr/local/install/4.3.1/lib/libgobject-2.0.so.0 (0x00007f28cd0b6000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007f28cceb1000) libglib-2.0.so.0 => /usr/local/install/4.3.1/lib/libglib-2.0.so.0 (0x00007f28ccbcf000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f28cc8c3000) libm.so.6 => /lib/libm.so.6 (0x00007f28cc640000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f28cc429000) libc.so.6 => /lib/libc.so.6 (0x00007f28cc0d6000) libselinux.so.1 => /lib/libselinux.so.1 (0x00007f28cbeba000) /lib64/ld-linux-x86-64.so.2 (0x00007f28cde86000) > uname -a Linux hikaru 2.6.25-2-amd64 #1 SMP Mon Jul 14 11:05:23 UTC 2008 x86_64 GNU/Linux If I first start the program and later attach to it, there are no problems. Release: 6.8 Environment: debian Lenny
Comment 1 Christopher Grayce 2010-06-04 09:21:52 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
Comment 2 John Carter 2011-05-27 05:26:52 UTC
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)
Comment 3 John Carter 2011-05-27 05:34:33 UTC
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
Comment 5 Pedro Alves 2011-05-27 10:49:48 UTC
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?
Comment 6 Gary Benson 2011-05-27 11:03:46 UTC
Not sure how relevant this is, but there is a function libpthread_name_p defined in solib.c.
Comment 7 Pedro Alves 2011-05-27 11:08:00 UTC
Yeah, didn't look useful.
Comment 8 Gary Benson 2011-05-27 12:30:06 UTC
Fair enough :)
Comment 9 Pedro Alves 2011-06-01 15:48:33 UTC
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?
Comment 10 Pedro Alves 2011-06-01 15:53:25 UTC
Is there any reason glibc couldn't move the symbols it wants to check against to the private namespace (nptl_version ==> __nptl_version, etc.)?
Comment 11 Pedro Alves 2014-11-20 11:46:45 UTC
Filed glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17629