Bug 205179
| Summary: | GDB:Error while reading shared library symbols: | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | IBM Bug Proxy <bugproxy> |
| Component: | kernel | Assignee: | Roland McGrath <roland> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6 | CC: | aoliva, cagney, ezannoni, jan.kratochvil |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | powerpc | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.6.17-1.2633.fc6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-10 07:08:29 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: | 201888 | ||
Since you have discovered that this is a kernel error, please assign to the correct component, instead of gdb. The utrace code is still under stabilization, and it is known to have a few corner cases still to be dealt with. What version of the kernel have you tried? There have been a few fixes in fedora/rawhide since FC6 test 2. Does ths occur with the latest rawhide kernel? Please indicate whether this was ppc32 or ppc64 gdb, and whether the program being debugged is ppc32 or ppc64. Please cite the particular kernel rpm versions that have been tested. Reproduced on my upstream kernel using 32-bit gdb on a 64-bit kernel. I have a fix. ----- Additional Comments From sharyathi.com 2006-09-07 14:04 EDT -------
Roland McGrath
When can we expect the fix from you on this problem
Thanks
The fix is included in kernel-2.6.17-1.2633.fc6 and later, which have not yet made it to rawhide but should before long. changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|FIXEDAWAITINGTEST |TESTED
------- Additional Comments From yuweiy.com 2006-09-19 00:10 EDT -------
Build kernel-2.6.17-1.2647.fc6 from
ftp://software.linux.ibm.com/pub/fedora/core/development/source/SRPMS/, and the
"reading shared library symbols" error has disappeared, but there is another
problem -- gdb can not singlestep over pthread function.
==============================
[root@blade9 gdb]# gdb tbug.32
GNU gdb Red Hat Linux (6.5-3.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ppc-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /toolchain/testbucket/test-tools/gdb/tbug.32
[Thread debugging using libthread_db enabled]
[New Thread -134479872 (LWP 2124)]
[New Thread -134482736 (LWP 2127)]
tf(0): begin
tf(0): end
[Thread -134482736 (LWP 2127) exited]
[New Thread -144968496 (LWP 2128)]
after create
tf(1): begin
tf(1): end
[Thread -144968496 (LWP 2128) exited]
after join
Program exited normally.
(gdb) b main
Breakpoint 1 at 0x10000624: file tbug.c, line 30.
(gdb) r
Starting program: /toolchain/testbucket/test-tools/gdb/tbug.32
[Thread debugging using libthread_db enabled]
[New Thread -134479872 (LWP 2129)]
[Switching to Thread -134479872 (LWP 2129)]
Breakpoint 1, main (argc=1, argv=0xf9a0fa74) at tbug.c:30
30 for (n = 0; n < N; ++n)
(gdb) s
31 if (pthread_create (&th[n], NULL, tf, (void *) (long int) n) != 0)
(gdb) s
0x10000ab0 in call___do_global_ctors_aux ()
(gdb) s
Single stepping until exit from function call___do_global_ctors_aux,
which has no line number information.
0x0e8068a0 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0
(gdb) s
Single stepping until exit from function pthread_create@@GLIBC_2.1,
which has no line number information.
0x0e8128c0 in call___do_global_ctors_aux () from /lib/libpthread.so.0
(gdb) s
Single stepping until exit from function call___do_global_ctors_aux,
which has no line number information.
0x0ff25f40 in getpagesize () from /lib/libc.so.6
(gdb) s
Single stepping until exit from function getpagesize,
which has no line number information.
0x0e806958 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0
(gdb) s
Single stepping until exit from function pthread_create@@GLIBC_2.1,
which has no line number information.
------------->hang here
Regarding "hang here" - have been told by <jakub> yesterday that gdb
currently does not support single-stepping through "Reserved"-utilizing code
http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm
as each single-step resets the Reservation and so the loop deadlocks.
Sorry if it is irrelevant here - I did not yet try to reproduce this case.
Yes, the bug is due to looping due to the Reservation, looping inside: 0x0fc45d58 <pthread_create@@GLIBC_2.1+268>: lwarx r3,0,r28 0x0fc45d5c <pthread_create@@GLIBC_2.1+272>: cmpw r3,r29 0x0fc45d60 <pthread_create@@GLIBC_2.1+276>: bne- 0xfc45d6c <pthread_create@@GLIBC_2.1+288> 0x0fc45d64 <pthread_create@@GLIBC_2.1+280>: stwcx. r0,0,r28 0x0fc45d68 <pthread_create@@GLIBC_2.1+284>: bne- 0xfc45d58 <pthread_create@@GLIBC_2.1+268> Cloning as a different Bug, only for Component "gdb". The cloned Bug is 207287, technically unrelated to this one. This was fixed in fc6. |
LTC Owner is: sharyathi.com LTC Originator is: yuweiy.com Problem description: Error while reading shared library symbols with gdb. Steps to reproduce: [root@blade9 gdb]# cat tbug.c /* File tbug.c created by Steve Munroe on Thu Jan 15 2004. */ #include <string.h> #include <unistd.h> #include <pthread.h> #include <stdlib.h> #include <stdio.h> #include <errno.h> #define N 2 static void * tf (void *arg) { int n = (int) (long int) arg; char number[160]; sprintf(number, "tf(%ld): begin", (long)arg); puts (number); sprintf(number, "tf(%ld): end", (long)arg); puts (number); return NULL; } int main (int argc, char *argv[]) { int n; pthread_t th[N]; for (n = 0; n < N; ++n) if (pthread_create (&th[n], NULL, tf, (void *) (long int) n) != 0) { puts ("create failed"); exit (1); } puts("after create"); for (n = 0; n < N; ++n) if (pthread_join (th[n], NULL) != 0) { puts ("join failed"); exit (1); } puts("after join"); return 0; } /* Change Log <@log@> Thu Jan 15 2004 13:44:33 by Steve Munroe <reason><version><Brief description and why change was made.> */ [root@blade9 gdb]# gcc -o tbug tbug.c -lpthread [root@blade9 gdb]# gdb tbug GNU gdb Red Hat Linux (6.5-3.fc6rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ppc-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /toolchain/testbucket/test-tools/gdb/tbug [Thread debugging using libthread_db enabled] Error while reading shared library symbols: reading register f0 (#32): Input/output error. reading register f0 (#32): Input/output error. (gdb) Additional information: [root@blade9 gdb]# rpm -q gdb gdb-6.5-3.fc6 The error is coming from this part of the code in ppc-linux-nat.c ==================== for (bytes_transferred = 0; bytes_transferred < register_size (current_gdbarch, regno); bytes_transferred += sizeof (long)) { errno = 0; *(long *) &buf[bytes_transferred] = ptrace (PTRACE_PEEKUSER, tid, (PTRACE_TYPE_ARG3) regaddr, 0); regaddr += sizeof (long); if (errno != 0) { char message[128]; sprintf (message, "reading register %s (#%d)", REGISTER_NAME (regno), regno); } } ==================== ptrace is faulting for register #32 ie f0 or first floating point register. The Problem seems to be with utrace code, I rebuilt the kernel without the linux-2.6-utrace.patch and the problem was not noticed. Please mirror the bug to RedHat's awareness. Thanks.