Bug 123907 - GDB fails to handle libraries properly
GDB fails to handle libraries properly
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elena Zannoni
:
: 124816 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-21 12:03 EDT by Alan Cox
Modified: 2007-11-30 17:10 EST (History)
8 users (show)

See Also:
Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-19 05:50:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alan Cox 2004-05-21 12:03:39 EDT
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.
Comment 1 daniel 2004-05-25 23:12:16 EDT
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
Comment 2 daniel 2004-05-25 23:29:48 EDT
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
Comment 3 Alan Cox 2004-05-26 05:53:16 EDT
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
Comment 4 daniel 2004-05-26 12:20:03 EDT
thanks alan, not full debug symbols for everything... just for 
libthread_db.so and dependencies...

good coding,
daniel
Comment 5 daniel 2004-05-26 12:39:10 EDT
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
Comment 6 daniel 2004-05-26 12:41:28 EDT
i'll build a gdb from scratch, just to see what happens...
can a gcc bootstrapping help? kinda like doubt it...

gc,
d
Comment 7 daniel 2004-05-26 13:02:32 EDT
i'll build a gdb from scratch, just to see what happens...
can a gcc bootstrapping help? kinda like doubt it...

gc,
d
Comment 8 daniel 2004-05-26 13:12:09 EDT
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
Comment 11 Elena Zannoni 2004-05-26 14:04:59 EDT
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.
Comment 12 daniel 2004-05-26 15:09:58 EDT
super, will do so... thanks elena
please let us know when you have this fixed (the sooner the merrier)
gc
d
Comment 13 yeech 2004-05-28 16:25:40 EDT
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)


Comment 14 Miloslav Trmac 2004-05-31 09:51:21 EDT
*** Bug 124816 has been marked as a duplicate of this bug. ***
Comment 15 Stephan Menzel 2004-06-03 06:11:57 EDT
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

Comment 16 Chris Micallef 2004-06-03 10:39:29 EDT
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. 
Comment 17 Chris Micallef 2004-06-03 10:40:07 EDT
/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  
  
Comment 18 Stephan Menzel 2004-06-07 05:27:19 EDT
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
Comment 19 Scott Shandler 2004-06-14 20:32:01 EDT
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
Comment 20 Chris Micallef 2004-07-12 07:46:57 EDT
Was there any patch for this problem or any solutions to get kdevelop 
3 to debug programs with gdb?  
 
Thx 
Comment 21 Elena Zannoni 2004-08-27 08:58:42 EDT
Have you tried the latest gdb-6.1post-0.20040607 ? I really think it
was due to problems with PIE executables.
Comment 22 Stephan Menzel 2004-08-28 05:23:02 EDT
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 
 
Comment 23 Yizheng Cai 2004-09-16 14:29:11 EDT
Is gdb-6.1post-0.20040607 to solve the gdb problem with Fedora Core 2? 
Comment 24 Chris Micallef 2004-09-16 14:32:56 EDT
yes it did solve the problem on kdevelop 3, I can now debug and trace 
through.  
Comment 25 Matthew Miller 2005-04-26 11:38:10 EDT
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.
Comment 26 Alan Cox 2006-01-19 05:50:01 EST
FC4 seems happy. Closing

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