Bug 82640
| Summary: | Gdb unable to debug threaded apps | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 2.1 | Reporter: | Johan Walles <johan.walles> | ||||
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Jay Turner <jturner> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 2.1 | CC: | dhoward, dstownse, ezannoni, fweimer, lakamine, mherrick, msimons, psessions, randall.ross, roland, srevivo, steve.brenneis, suhua.ding, tao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2003-08-22 21:09:30 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 87937 | ||||||
| Attachments: |
|
||||||
|
Description
Johan Walles
2003-01-24 12:10:11 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).
FWIW I get the same result with a home-brew gdb 5.3 on this system. 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 :-). thanks for the suggestion. I will add the dependency to the spec file from now on. But it is a glibc problem, not a gdb one. 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! Oversight on my part. The arch for this has been changed to 'all'. 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 */ };
+
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 */ };
+
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. Should be fixed in glibc-2.2.4-32.3. *** Bug 88698 has been marked as a duplicate of this bug. *** 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 glibc-2.2.4-32.3 does not correct this. Initial customer feedback is that this patch appears to correct the issue. Will follow up if further testing does not corroborate this. 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 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? 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)
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. 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
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. 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 ). 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 |