Fedora Account System
Red Hat Associate
Red Hat Customer
If you dump something like /bin/cat then gdb it and the core file you get GNU gdb Red Hat Linux (6.0post-0.20040223.19rh) Copyright 2004 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 "i386-redhat-linux-gnu"...(no debugging symbols found )...Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `cat'. Program terminated with signal 3, Quit. warning: svr4_current_sos: Can't read pathname for load map: Input/output error Error while mapping shared library sections: : Success. Error while reading shared library symbols: : No such file or directory. and it then goes on to vaguely work.
cannot believe my eyes, got exactly the same symptoms... it's like nobody ever used gdb with fc2?!? please lemme know over email when you add the symbols to all the sys libraries thanks & good coding, daniel
gdb from cli is one thing, but hey, implicitly is affecting kdevelop and whatever other tools invoking gdb (e.g. borland cbuildex, etc) daniel - borland
As far as I can tell the base symbols are all there, but gdb isn't loading them. The full debug symbols are in the .debuginfo packages on the ftp site (they aren't on the CD sets because full debug info for many of the packages would be several more CD-ROMs
thanks alan, not full debug symbols for everything... just for libthread_db.so and dependencies... good coding, daniel
here is what i get (in more obvious details): gdb hieveryone GNU gdb Red Hat Linux (6.0post-0.20040223.19rh) blah... This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) list 21 #ifdef HAVE_CONFIG_H 22 #include <config.h> 23 #endif 24 25 #include <stdio.h> 26 #include <stdlib.h> 27 28 int main(int argc, char *argv[]) 29 { 30 printf("Hello, world!\n"); (gdb) break 30 Breakpoint 1 at 0x8048379: file hieveryone.c, line 30. (gdb) run Starting program: /temp/hieveryone/src/hieveryone Error while mapping shared library sections: : Success. Error while reading shared library symbols: : No such file or directory. // here we go! Error while reading shared library symbols: : No such file or directory. // here we go again! Error while reading shared library symbols: : No such file or directory. // here we go again! Breakpoint 1, main (argc=1, argv=0xfef057e4) at hieveryone.c:30 30 printf("Hello, world!\n"); (gdb) ... have a feeling that it's something to do with selinux?.... ps please keep me in touch on this issue... thx & good coding, daniel
i'll build a gdb from scratch, just to see what happens... can a gcc bootstrapping help? kinda like doubt it... gc, d
ldd-ing libthread_db.so.1 you get to libc.so.6 (among other things) ldd-ing libc.so.6 you get to: ld-linux.so.2 (statically linked - EOF) linux-gate.so.1 => (0x0042d000) //not deployed! am I missing something? hope this helps... regards, daniel
http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/4464.html ... d
http://www.uwsg.iu.edu/hypermail/linux/kernel/0306.3/0281.html :-) d
yes, it's a bad interaction between the code to handle PIE and the new vsyscall DSO. Something is very likely screwed up in the linkmap, i.e. it breaks some (probably highly stupid) assumption that gdb makes. Maybe if you comment out the pie patches in the spec file, and rebuild, it would get you somewhere, while I figure out a real fix.
super, will do so... thanks elena please let us know when you have this fixed (the sooner the merrier) gc d
This is my take on the problem. My opologies if I'm off base. gdb on the run command attempts to locate libraries built with debug information (see attached). gdb executed from the command line produces the error output and the human (me) ignores it and the debug session continues. KDbg ignores the errors as well but, KDevelop does not. KDevelop stops the debug session in its tracks (at least this is what I can understand from the interface). I believe that this behavior is documented in section 15.2 of the gdb users guide. Are libraries available in the FC2* distribution that contain debug information? Rob Shewan Advanced Acoustic Concepts This is an extract of an strace of gdb. stat64("", 0xfeef3c2c) = -1 ENOENT (No such file or directory) open("/usr/lib/libstdc++.so.5.0.5.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/.debug/libstdc++.so.5.0.5.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/debug//usr/lib/libstdc++.so.5.0.5.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libm-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/.debug/libm-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/debug//lib/tls/libm-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libgcc_s-3.3.3-20040413.so.1.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/.debug/libgcc_s-3.3.3-20040413.so.1.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/debug//lib/libgcc_s-3.3.3-20040413.so.1.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libc-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/.debug/libc-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/debug//lib/tls/libc-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/ld-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/.debug/ld-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/debug//lib/ld-2.3.3.so.debug", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("", 0xfeef3c2c) = -1 ENOENT (No such file or directory) stat64("", 0xfeef3c2c) = -1 ENOENT (No such file or directory)
*** Bug 124816 has been marked as a duplicate of this bug. ***
I have the same problem since I updated from redhat9 to FC2. gdb never worked since. This is what I get, if that helps you: (gdb) run Error while mapping shared library sections: : Success. (gdb) backtrace Error while reading shared library symbols: : File or directory not found. Stopped due to shared library event #0 0x003f3ff0 in _dl_debug_state () from /lib/ld-linux.so.2 #1 0x003e9964 in dl_main () from /lib/ld-linux.so.2 #2 0x003f6910 in _dl_sysdep_start () from /lib/ld-linux.so.2 #3 0x003e8acf in _dl_start () from /lib/ld-linux.so.2 #4 0x003e87e7 in _start () from /lib/ld-linux.so.2 (gdb) frame 0 #0 0x003f3ff0 in _dl_debug_state () from /lib/ld-linux.so.2 This is a highly inconvenient bug for me since I use this machine mainly for coding and that isn't fun anymore without gdb at my side. So if there is any solution, please post it. Thanks... Stephan
Hi when I place a breakpoint under kdevelop 3 and start debug I get the following error and gdb stops : "Error while reading shared library symbols:: No such file or directory", This can be reproduced by creating a simpile KDE Application with kdevelop 3 and place breakpoint somewhere in main and start debug.
/bin/sh -c /home/chris/test/debug/libtool gdb /home/chris/test/debug/src/test -fullname -nx -quiet (gdb) set edit off (gdb) set confirm off *** Warning: inferring the mode of operation is deprecated. *** Future versions of Libtool will require -mode=MODE be specified. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) (gdb) (gdb) set print static-members off (gdb) tty /dev/pts/12 (gdb) set width 0 (gdb) set height 0 (gdb) set stop-on 1 (gdb) handle SIG32 pass nostop noprint (gdb) handle SIG43 pass nostop noprint (gdb) set print asm-demangle on (gdb) cd /home/chris/test/debug/src (gdb) break main.cpp:45 Breakpoint 1 at 0x804d227: file /home/chris/test/src/main.cpp, line 45. (gdb) run Error while mapping shared library sections: : Success. (gdb) backtrace Error while reading shared library symbols: : No such file or directory. [Thread debugging using libthread_db enabled] [New Thread -150313888 (LWP 9489)] Stopped due to shared library event #0 0x009a6480 in _dl_debug_state () from /lib/ld-linux.so.2 #1 0x0099b961 in dl_main () from /lib/ld-linux.so.2 #2 0x009a8e14 in _dl_sysdep_start () from /lib/ld-linux.so.2 #3 0x0099aac0 in _dl_start () from /lib/ld-linux.so.2 #4 0x0099a7c7 in _start () from /lib/ld-linux.so.2 (gdb) info thread [New Thread -150313888 (LWP 9489)] 2 Thread -150313888 (LWP 9489) 0x009a6480 in _dl_debug_state () from /lib/ld-linux.so.2 (gdb) frame 0 #0 0x009a6480 in _dl_debug_state () from /lib/ld-linux.so.2
I'm not so sure anymore, if that's really a bug in gdb since I just noticed, that the Kgdb frontend I never used before (always KDevelop) seems to work fine. The bug doesn't appear. On the other hand valgrind crashes as well with that: relocation error: /usr/lib/valgrind/valgrind.so: symbol __libc_accept, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference I didn't have time to figure out what kgdb does differently to KDevelop but if there's something, that might be an important clue. Stephan
I think the issue might have to with the tty command that kdevelop seems to automatically place in the gdb session. If you issue the same commands in terminal GDB skipping the tty line, you can run the program without a problem. Anyone know how to make kdevelop stop issuing that line? tty /dev/pts/<insert number here> just my two cents. I am also anxiously waiting for an answer?!?!?! -Scott
Was there any patch for this problem or any solutions to get kdevelop 3 to debug programs with gdb? Thx
Have you tried the latest gdb-6.1post-0.20040607 ? I really think it was due to problems with PIE executables.
Well, I used the one that commeth with the FC2 distri. Regular updates of course but I've set up several FC2 boxes now, some updated some freshly installed and all of them have this problem. gdb -version says: GNU gdb Red Hat Linux (6.0post-0.20040223.19rh) Kgdb works fine though. Stephan
Is gdb-6.1post-0.20040607 to solve the gdb problem with Fedora Core 2?
yes it did solve the problem on kdevelop 3, I can now debug and trace through.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
FC4 seems happy. Closing