Bug 9635

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

[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