Bug 9635 - Cannot find new threads: generic error
Summary: Cannot find new threads: generic error
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: threads (show other bugs)
Version: 7.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 17629
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-27 17:38 UTC by Carlo Wood
Modified: 2014-11-20 11:46 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Very short file that "kills gdb". (81 bytes, text/plain)
2011-05-27 05:26 UTC, John Carter
Details
fix (661 bytes, patch)
2011-05-27 10:46 UTC, Pedro Alves
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 4 Pedro Alves 2011-05-27 10:46:01 UTC
Created attachment 5757 [details]
fix
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