Description of problem: I have glibc-debuginfo installed. The following happens. [notting@nostromo: ~]$ cat foo.c #include <stdio.h> int main() { printf("%s\n", 4); } [notting@nostromo: ~]$ cat foo.c #include <stdio.h> int main() { printf("%s\n", 4); } [notting@nostromo: ~]$ gcc -g -o foo foo.c [notting@nostromo: ~]$ gdb ./foo GNU gdb (GDB) Fedora (6.8.50.20081214-1.fc11) 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-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... (gdb) run Starting program: /home/notting/foo Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7ce9f00 in ?? () (gdb) bt #0 0x00007ffff7ce9f00 in ?? () #1 0x00007ffff7cb266e in ?? () #2 0x00000000004002f0 in ?? () #3 0x0000000000118beb in _dl_map_object (loader=0x4, name=0x7fffffffe130 "0����\177", preloaded=0, type=1, trace_mode=0, mode=0, nsid=115) at dl-load.c:2239 #4 0x000000000011073c in ?? () from /lib64/ld-linux-x86-64.so.2 #5 0x00007ffff7c79270 in ?? () #6 0x0000000000110410 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x0000000000000000 in ?? () (gdb) Version-Release number of selected component (if applicable): gcc-4.3.2-7.x86_64 glibc-2.9.90-2.x86_64 gdb-6.8.50.20081214-1.fc11.x86_64 How reproducible: 100% Steps to Reproduce: 1. Build a program 2. Attempt to debug it Actual results: FAIL Expected results: WIN Additional info:
Works for me: $ gdb ./foo GNU gdb (GDB) Fedora (6.8.50.20081214-1.fc11) 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-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... (gdb) r Starting program: /root/jkratoch/redhat/foo Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:37 37 0: cmpb $0x0,(%rax) /* is byte NUL? */ Current language: auto; currently asm (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:37 #1 0x00007ffff7cc666e in _IO_vfprintf_internal (s=0x7ffff7fe9780, format=<value optimized out>, ap=0x7fffffffd4c0) at vfprintf.c:1581 #2 0x00007ffff7ccceca in __printf (format=<value optimized out>) at printf.c:35 #3 0x00000000004004e8 in main () at foo.c:4 (gdb) q Using: gdb-6.8.50.20081214-1.fc11.x86_64 glibc-2.9.90-2.x86_64 glibc-debuginfo-2.9.90-2.x86_64 gcc-4.3.2-7.x86_64 kernel-2.6.27.5-117.fc10.x86_64 Could not use: kernel-2.6.29-0.25.rc0.git14.fc11.x86_64 on gs-bl460cg1-01.rhts.bos.redhat.com due to: Reading all physical volumes. This may take a while... Volume group "VolGroup00" not found Unable to access resume device (/dev/VolGroup00/LogVol01) mount: error mounting /dev/root on /sysroot as ext3: No such file or directory expecting due to the open Bug 429937 (or a new Bug?). Also the latest stable kernel updates for F-9/F-10/Rawhide are not usable for GDB (using custom build kernel-2.6.27.9-163.ptrace.fc10.x86_64) - Bug 475645. Do your glibc and glibc-debuginfo versions match? It could be Bug 478426 probably due to some rpms distribution delay. This whole version matching problem is either due to YUM (Bug 432806) or RPM (Bug 151598).
glibc-2.9.90-2.x86_64 glibc-debuginfo-2.9.90-2.x86_64 Currently running 2.6.29-0.18.rc0.git9.fc11.x86_64 - will try an older kernel shortly.
Debugging works fine under 2.6.27.9-159.fc10.x86_64. Pushing to kernel.
*** This bug has been marked as a duplicate of bug 475645 ***
Hm, 475645 doesn't show the same symptoms I see - I don't see spurious SIGTRAPs. It just can't map stack frames to anything useful.
That Bug 475645 is in fact a group of 4 Bugs. One needs to first update the tests status at http://sourceware.org/systemtap/wiki/utrace/tests which is now being discussed whether should be done by Denys Vlasenko or me as before. Then Roland McGrath needs to fix all the known failures of existing ptrace-testsuite testcases for ptrace-emulated-by-utrace and then one needs to verify these (currently 4 Bugs) if they got fixed - and possibly create a new testcases for ptrace-testsuite if not. This is the plan as seen by me.