Bug 82640 - Gdb unable to debug threaded apps
Summary: Gdb unable to debug threaded apps
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc
Version: 2.1
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Jay Turner
URL:
Whiteboard:
: 88698 (view as bug list)
Depends On:
Blocks: 87937
TreeView+ depends on / blocked
 
Reported: 2003-01-24 12:10 UTC by Johan Walles
Modified: 2016-11-24 12:27 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-08-22 21:09:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
A simple threaded test program. Build with "-g -lpthread" (1.99 KB, text/plain)
2003-01-24 12:18 UTC, Johan Walles
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:090 0 high SHIPPED_LIVE Critical: glibc security update 2003-05-22 04:00:00 UTC
Red Hat Product Errata RHSA-2003:249 0 normal SHIPPED_LIVE Important: glibc security update 2003-08-22 04:00:00 UTC

Description Johan Walles 2003-01-24 12:10:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

Description of problem:
AFAICT, gdb cannot debug anything linked to libpthread.  I *think* the RHAS
version is "Q1 Errata Beta", but I'm not sure.  The exact versions of relevant
packages are:

gdb-5.2-2
ncurses-5.2-12
glibc-2.2.4-31.7
kernel-smp-2.4.18-e.14

/proc/version says:

Linux version 2.4.18-e.14smp (bhcompile.redhat.com) (gcc version
2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)) #1 SMP Thu Jan 16 22:08:18 EST 2003


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. gdb -nx pthread_create
2. break main
3. run


Actual Results:
Starting program: /home/johan/src/test/pthread_create 
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find user-level thread for LWP 10411: no LWP to satisfy query


Expected Results:  The program should have started and then stopped at the
breakpoint in main().

Additional info:

I can't say for sure that the above versions are current for RHAS/ia64.  I
*think so*, but I'm really not sure.  So this *may* just be a matter of me not
being up to date enough.

Also, severity high because this stops most of our development on RHAS/ia64
(which may affect other people as well).

Comment 1 Johan Walles 2003-01-24 12:18:52 UTC
Created attachment 89569 [details]
A simple threaded test program.  Build with "-g -lpthread"

The test program wasn't really created for testing this, so it does some other
junk as well (but works fine as a test case for this).

Comment 2 Johan Walles 2003-01-24 13:00:02 UTC
FWIW I get the same result with a home-brew gdb 5.3 on this system.


Comment 3 Johan Walles 2003-01-24 16:40:37 UTC
Downgrading glibc to glibc-2.2.4-29.2 fixes this problem.

Since we don't have any dependencies on any particular glibc version we'll just
downgrade glibc on our development machines, but you probably want to fix this
anyway.  We are not panicking anymore anyway :-).


Comment 4 Elena Zannoni 2003-01-27 16:53:58 UTC
thanks for the suggestion. I will add the dependency to the spec file from now
on. 

Comment 6 Elena Zannoni 2003-04-04 19:22:01 UTC
But it is a glibc problem, not a gdb one.



Comment 10 Johan Walles 2003-04-04 20:59:54 UTC
fhirtz: Why did you change the platform to i686?  As the original reporter of
this bug I can say for sure it exists on ia64, but I don't know about i686.  If
you see it on i686 as well, shouldn't the Platform be All rather than i686?

Having this fixed on ia64 would be great!

Comment 11 Frank Hirtz 2003-04-04 21:16:24 UTC
Oversight on my part. The arch for this has been changed to 'all'.

Comment 12 Don Howard 2003-04-04 22:16:42 UTC
The following glibc patch re-introduces the static thread handle initalizer 
and seems to fix the problem. (This patch replaces the maxthreads patch in the 
2.2.4-31.7 src rpm.)


--- linuxthreads/pthandles.c.dh Fri Apr  4 09:11:57 2003
+++ linuxthreads/pthandles.c    Fri Apr  4 09:18:35 2003
@@ -0,0 +1,9 @@
+#include <ldsodefs.h>
+#include "pthread.h"
+#include "internals.h"
+
+/* Array of active threads. Entry 0 is reserved for the initial thread. */
+struct pthread_handle_struct __pthread_handles[PTHREAD_THREADS_MAX] =
+{ { __LOCK_INITIALIZER, &__pthread_initial_thread, 0},
+  { __LOCK_INITIALIZER, &__pthread_manager_thread, 0}, /* All NULLs */ };
+



Comment 13 Don Howard 2003-04-04 22:30:16 UTC
Sorry, folks - the above is only a partial patch. Here's a full replacement 
for the maxthreads patch:


2003-04-04  Don Howard  <dhoward>

	* pthandles.c: Reintroduce the static thread handle initializer.
	GDB can't locate threads if __pthread_handles is uninitalized. See
	bugzilla 82640.

2002-08-08  Jakub Jelinek  <jakub>

	* sysdeps/unix/sysv/linux/bits/local_lim.h (PTHREAD_THREADS_MAX):
	Bump to 8192.
	* manager.c (__pthread_handles): Remove.
	* pthandles.c: New file.
	* pthread.c (__pthread_initialize_minimal): Initialize
	__pthread_handles[0] and __pthread_handles[1].
	* Makefile (libpthread-routines): Add pthandles (must be last).



--- libc/linuxthreads/sysdeps/unix/sysv/linux/bits/local_lim.h.jj	Tue 
Jun 13 01:29:21 2000
+++ libc/linuxthreads/sysdeps/unix/sysv/linux/bits/local_lim.h	Sat Oct 26 
18:00:59 2002
8of threads per process.  */
 #define _POSIX_THREAD_THREADS_MAX	64
 /* This is the value this implementation supports.  */
-#define PTHREAD_THREADS_MAX	1024
+#define PTHREAD_THREADS_MAX	8192
 
 /* Maximum amount by which a process can descrease its asynchronous I/O
    priority level.  */
--- libc/linuxthreads/manager.c.jj	Tue Sep 18 07:38:24 2001
+++ libc/linuxthreads/manager.c	Sat Oct 26 18:02:27 2002
5rt.h"
 #include "semaphore.h"
 
-/* Array of active threads. Entry 0 is reserved for the initial thread. */
-struct pthread_handle_struct __pthread_handles[PTHREAD_THREADS_MAX] =
-{ { __LOCK_INITIALIZER, &__pthread_initial_thread, 0},
-  { __LOCK_INITIALIZER, &__pthread_manager_thread, 0}, /* All NULLs */ };
-
 /* For debugging purposes put the maximum number of threads in a variable.  */
 const int __linuxthreads_pthread_threads_max = PTHREAD_THREADS_MAX;
 
--- libc/linuxthreads/Makefile.jj	Wed Jul 25 17:24:09 2001
+++ libc/linuxthreads/Makefile	Sat Oct 26 18:03:08 2002
@@ -36,7 +36,7 @@ libpthread-routines := attr cancel condv
 		       ptlongjmp pthread signals specific errno lockfile \
 		       semaphore spinlock wrapsyscall rwlock pt-machine \
 		       oldsemaphore events getcpuclockid pspinlock barrier \
-		       ptclock_gettime ptclock_settime
+		       ptclock_gettime ptclock_settime pthandles
 
 nodelete-yes = -Wl,--enable-new-dtags,-z,nodelete
 initfirst-yes = -Wl,--enable-new-dtags,-z,initfirst
--- libc/linuxthreads/pthread.c.jj	Tue Sep 18 07:38:24 2001
+++ libc/linuxthreads/pthread.c	Sat Oct 26 18:05:29 2002
@@ -390,6 +390,14 @@ extern void *__dso_handle __attribute__ 
 void
 __pthread_initialize_minimal(void)
 {
+  /* First of all init __pthread_handles[0] and [1].  */
+#if __LT_SPINLOCK_INIT != 0
+  __pthread_handles[0].h_lock = __LOCK_INITIALIZER;
+  __pthread_handles[1].h_lock = __LOCK_INITIALIZER;
+#endif
+  __pthread_handles[0].h_descr = &__pthread_initial_thread;
+  __pthread_handles[1].h_descr = &__pthread_manager_thread;
+
   /* If we have special thread_self processing, initialize that for the
      main thread now.  */
 #ifdef INIT_THREAD_SELF
--- linuxthreads/pthandles.c.dh Fri Apr  4 09:11:57 2003
+++ linuxthreads/pthandles.c    Fri Apr  4 09:18:35 2003
@@ -0,0 +1,9 @@
+#include <ldsodefs.h>
+#include "pthread.h"
+#include "internals.h"
+
+/* Array of active threads. Entry 0 is reserved for the initial thread. */
+struct pthread_handle_struct __pthread_handles[PTHREAD_THREADS_MAX] =
+{ { __LOCK_INITIALIZER, &__pthread_initial_thread, 0},
+  { __LOCK_INITIALIZER, &__pthread_manager_thread, 0}, /* All NULLs */ };
+
2003-04-04  Don Howard  <dhoward>

	* pthandles.c: Reintroduce the static thread handle initializer.
	GDB can't locate threads if __pthread_handles is uninitalized. See
	bugzilla 82640.

2002-08-08  Jakub Jelinek  <jakub>

	* sysdeps/unix/sysv/linux/bits/local_lim.h (PTHREAD_THREADS_MAX):
	Bump to 8192.
	* manager.c (__pthread_handles): Remove.
	* pthandles.c: New file.
	* pthread.c (__pthread_initialize_minimal): Initialize
	__pthread_handles[0] and __pthread_handles[1].
	* Makefile (libpthread-routines): Add pthandles (must be last).



--- libc/linuxthreads/sysdeps/unix/sysv/linux/bits/local_lim.h.jj	Tue 
Jun 13 01:29:21 2000
+++ libc/linuxthreads/sysdeps/unix/sysv/linux/bits/local_lim.h	Sat Oct 26 
18:00:59 2002
8of threads per process.  */
 #define _POSIX_THREAD_THREADS_MAX	64
 /* This is the value this implementation supports.  */
-#define PTHREAD_THREADS_MAX	1024
+#define PTHREAD_THREADS_MAX	8192
 
 /* Maximum amount by which a process can descrease its asynchronous I/O
    priority level.  */
--- libc/linuxthreads/manager.c.jj	Tue Sep 18 07:38:24 2001
+++ libc/linuxthreads/manager.c	Sat Oct 26 18:02:27 2002
5rt.h"
 #include "semaphore.h"
 
-/* Array of active threads. Entry 0 is reserved for the initial thread. */
-struct pthread_handle_struct __pthread_handles[PTHREAD_THREADS_MAX] =
-{ { __LOCK_INITIALIZER, &__pthread_initial_thread, 0},
-  { __LOCK_INITIALIZER, &__pthread_manager_thread, 0}, /* All NULLs */ };
-
 /* For debugging purposes put the maximum number of threads in a variable.  */
 const int __linuxthreads_pthread_threads_max = PTHREAD_THREADS_MAX;
 
--- libc/linuxthreads/Makefile.jj	Wed Jul 25 17:24:09 2001
+++ libc/linuxthreads/Makefile	Sat Oct 26 18:03:08 2002
@@ -36,7 +36,7 @@ libpthread-routines := attr cancel condv
 		       ptlongjmp pthread signals specific errno lockfile \
 		       semaphore spinlock wrapsyscall rwlock pt-machine \
 		       oldsemaphore events getcpuclockid pspinlock barrier \
-		       ptclock_gettime ptclock_settime
+		       ptclock_gettime ptclock_settime pthandles
 
 nodelete-yes = -Wl,--enable-new-dtags,-z,nodelete
 initfirst-yes = -Wl,--enable-new-dtags,-z,initfirst
--- libc/linuxthreads/pthread.c.jj	Tue Sep 18 07:38:24 2001
+++ libc/linuxthreads/pthread.c	Sat Oct 26 18:05:29 2002
@@ -390,6 +390,14 @@ extern void *__dso_handle __attribute__ 
 void
 __pthread_initialize_minimal(void)
 {
+  /* First of all init __pthread_handles[0] and [1].  */
+#if __LT_SPINLOCK_INIT != 0
+  __pthread_handles[0].h_lock = __LOCK_INITIALIZER;
+  __pthread_handles[1].h_lock = __LOCK_INITIALIZER;
+#endif
+  __pthread_handles[0].h_descr = &__pthread_initial_thread;
+  __pthread_handles[1].h_descr = &__pthread_manager_thread;
+
   /* If we have special thread_self processing, initialize that for the
      main thread now.  */
 #ifdef INIT_THREAD_SELF
--- linuxthreads/pthandles.c.dh Fri Apr  4 09:11:57 2003
+++ linuxthreads/pthandles.c    Fri Apr  4 09:18:35 2003
@@ -0,0 +1,9 @@
+#include <ldsodefs.h>
+#include "pthread.h"
+#include "internals.h"
+
+/* Array of active threads. Entry 0 is reserved for the initial thread. */
+struct pthread_handle_struct __pthread_handles[PTHREAD_THREADS_MAX] =
+{ { __LOCK_INITIALIZER, &__pthread_initial_thread, 0},
+  { __LOCK_INITIALIZER, &__pthread_manager_thread, 0}, /* All NULLs */ };
+



Comment 14 Roland McGrath 2003-04-09 01:17:45 UTC
I have isolated the libthread_db patch that should have been backported along
with the problematic libpthread patch (linuxthreads_db/td_ta_thr_iter.c).  I'll
work on an update with Jakub.  For those playing along at home, getting that
file from mainline glibc (or any rpm since glibc-2.2.90-24) should work.


Comment 15 Jakub Jelinek 2003-04-15 20:26:19 UTC
Should be fixed in glibc-2.2.4-32.3.

Comment 16 Don Howard 2003-05-21 19:41:42 UTC
*** Bug 88698 has been marked as a duplicate of this bug. ***

Comment 17 Mark J. Cox 2003-05-22 16:42:15 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2003-090.html


Comment 18 Don Howard 2003-05-22 18:01:37 UTC
glibc-2.2.4-32.3 does not correct this.


Comment 24 Frank Hirtz 2003-06-17 15:42:05 UTC
Initial customer feedback is that this patch appears to correct the issue. Will
follow up if further testing does not corroborate this. 

Comment 25 Need Real Name 2003-06-18 18:22:02 UTC
I've just installed Linux ES 2.1 Update 2, which comes pre-packaged with glibc-
2.2.24-32.3 (as well as gdb-5.2-2) and have the exact same problem - can't 
debug threaded applications:

Error while reading shared library symbols:
Cannot get thread info: generic error
Cannot find user-level thread for LWP 17127: no LWP to satisfy query

Comment 26 Mike Simons 2003-07-11 20:58:26 UTC
  We have two machines running RHAS and saw the bug listed above.  On one
machine the i386 version of glibc-2.2.4-32.3.i386.rpm was installed top fix the
problem on the other the i686 version was installed.  The i686 rpm does correct
this problem (gdb works correctly), the i386 rpm does not (gdb reports errors).
  Someone should look into the build differences between those two packages.

- What rpm command string are people supposed to use to identify *exactly* which
rpm's they have installed?

  rpm -qa is certainly not enough, because these machines both show the same
package list.  rpm -V checks them out as clean... yet a simple ls -l
/lib/libpthread* shows they have very different binaries.


- Could someone explain why i686 versions of -devel, and -profile are not available?

Comment 27 Jakub Jelinek 2003-07-23 20:24:20 UTC
a) e.g. rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc glibc-devel # etc.
b) i686 -devel/-profile packages are both undesirable and not needed
   glibc-devel package contains headers, which are the same between the two
   arches, symbolic links to shared libraries (again, the same) and .a libraries
   (linking statically against i686+ libraries would only cause confusion,
   because such binaries could not be run on any previous CPU)

Comment 28 Steve Brenneis 2003-07-28 17:18:28 UTC
glibc-2.2.4-32.3.i686 as applied by up2date on ES 2.1 does not correct the
problem. My ES distribution came with 2.2.4-31.7.

An earlier comment noted that downgrading to glibc-2.2.4-29.2 corrects the
problem, but I am unable to find anything other than a SRPM for that version. Is
there a binary RPM for that version?

This is a show-stopper for me.


Comment 29 Steve Brenneis 2003-07-28 19:27:53 UTC
Also note the following:

[root@NCD11081363 root]# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n'
glibc-devel
glibc-devel-2.2.4-32.3.i386
[root@NCD11081363 root]# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n'
glibc-common
glibc-common-2.2.4-32.3.i386
[root@NCD11081363 root]# ll /usr/lib/libpthread*
-rw-r--r--    1 root     root      1682770 Apr  9 03:59 /usr/lib/libpthread.a
lrwxrwxrwx    1 root     root           25 Jul  1 08:26 /usr/lib/libpthread.so
-> ../../lib/libpthread.so.0
[root@NCD11081363 root]# ll /lib/libpthread*
-rwxr-xr-x    1 root     root        71872 Apr  9 04:43 /lib/libpthread-0.9.so
lrwxrwxrwx    1 root     root           17 Jul  1 08:25 /lib/libpthread.so.0 ->
libpthread-0.9.so
[root@NCD11081363 root]# ll /usr/lib/libthread*
lrwxrwxrwx    1 root     root           27 Jul  1 08:26 /usr/lib/libthread_db.so
-> ../../lib/libthread_db.so.1
[root@NCD11081363 root]# ll /lib/libthread*
-rwxr-xr-x    1 root     root       264245 Apr  9 03:59 /lib/libthread_db-1.0.so
lrwxrwxrwx    1 root     root           19 Jul  1 08:25 /lib/libthread_db.so.1
-> libthread_db-1.0.so


Comment 30 Jakub Jelinek 2003-07-28 22:09:41 UTC
ftp://people.redhat.com/jakub/glibc/errata/2.2.4-32.7/
if you want to see thepackages earlier than when they complete the QA process.

Comment 31 Debby Townsend 2003-07-29 19:13:44 UTC
If you download the source rpm, it looks like the initialization in
linuxthreads/pthandles.c is not included. All the rest of the patch shown above is there -
including the initialization performed in __pthread_initialize_minimal().

When I added those two lines into pthandles.c ( via  glibc-2.2.4-maxthread.patch ) ;
rebuilt  the RPM; slotted the resulting /lib/i686/libpthread-0.9.so into place; and ran
ldconfig; this resolved this particular problem on my machine ( i686; AS2.1; gdb5.1-1; gcc
2.96 ).

( I previously did the above  without adding those two lines and still had the problem, so 
the recompilation itself was not a solution ).


Comment 35 David Lawrence 2003-08-22 21:09:30 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2003-249.html



Note You need to log in before you can comment on or make changes to this bug.