Bug 123907

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

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