Version: 3.0.3 (using KDE KDE 3.2.2) Installed from: RedHat RPMs Compiler: gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) OS: Linux When attempting to debug my application running on Fedora Core 2, the debugger looks for shared libraries and then dies, prior to acutually debugging the project. See transcript: /bin/sh -c /home/shandles/projects/tiger/libtool /usr/bin/gdb /home/shandles/projects/tiger/tiger/tiger -fullname -nx -quiet (gdb) set edit off (gdb) set confirm off (no debugging symbols found)... Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) (gdb) (gdb) set print static-members on (gdb) tty /dev/pts/57 (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/shandles/projects/tiger/tiger (gdb) set args /home/shandles/projects/tiger/tiger/input/gb.in (gdb) break main.cpp:44 No symbol table is loaded. Use the "file" command. (gdb) run Error while mapping shared library sections: : Success. (gdb) backtrace Error while reading shared library symbols: : No such file or directory. Stopped due to shared library event #0 0x0044a480 in _dl_debug_state () from /lib/ld-linux.so.2 #1 0x0043f961 in dl_main () from /lib/ld-linux.so.2 #2 0x0044ce14 in _dl_sysdep_start () from /lib/ld-linux.so.2 #3 0x0043eac0 in _dl_start () from /lib/ld-linux.so.2 #4 0x0043e7c7 in _start () from /lib/ld-linux.so.2 (gdb) frame 0 #0 0x0044a480 in _dl_debug_state () from /lib/ld-linux.so.2 This appears to be a problem with the way that kdevelop interacts with gdb. I ahve tried to run the same thing outside of KDevelop and if you skip the tty line ((gdb) tty /dev/pts/57 ), it seems to work fine. Otherwise it fails as shown above. If there is a way to control how kdevelop interacts with GDB that would be a nice thing to let us developers do. In addition, the project options window is rather confusing to use. A better organized way to set the project options, separate from the nice bells and whistles would be good too. Thanks for the mostly excellent work! -Scott
See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123907
I don't know if I agree this is a bug. I have no idea why we launch gdb like that, but it seems to have worked up until this Fedora release, and the Fedora bugzilla entry suggests they are aware they have a problem. If our way of launching gdb is wrong, we have a bug. If it's not wrong and should work, this is at most a wishlist to "make KDevelop optionally launch gdb in a different way".
Well, Since it prevents me from using the debugger, and I am unable to change the way KDevelop interacts with GDB, (I've really tried hard) I think that it should be listed as a bug, since the tty line is really unnecessary. Just my two cents. I wish this issue was able to be resolved so that I could use the new KDevelop, it is a show stopper for us here in the lab. Thanks, -Scott Quoting Jens Dagerbo <jens.dagerbo@swipnet.se>: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=83445 > jens.dagerbo swipnet se changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Component|general |debugger > > > > ------- Additional Comments From jens.dagerbo swipnet se 2004-06-16 18:45 > ------- > I don't know if I agree this is a bug. I have no idea why we launch gdb like > that, but it seems to have worked up until this Fedora release, and the > Fedora bugzilla entry suggests they are aware they have a problem. > > If our way of launching gdb is wrong, we have a bug. If it's not wrong and > should work, this is at most a wishlist to "make KDevelop optionally launch > gdb in a different way". >
Isn't the tty line necessary to get stdio in/out from a window? (When you run gdb in a shell you have no need to do that...) Lets take a look at the actual line again: "/home/shandles/projects/tiger/libtool /usr/bin/gdb /home/shandles/projects/tiger/tiger/tiger ..." But I do have some related problems... If I use the projects libtool like the example above - it does not work. But using the system default libtool does! "libtool /usr/bin/gdb ..."
~> $PWD/libtool --version ltmain.sh (GNU libtool) 1.4.1 (1.922.2.34 2001/09/03 01:22:13) ~> libtool --version ltmain.sh (GNU libtool) 1.5 (1.1220.2.1 2003/04/14 22:48:00) So, the one that does not work is older... Too old for the rest of my environment?
Update: I tried to create a new project - it did never create the "libtool"... Debug works from kdevelop. Please try to create and debug a new project.
Scott, You said it didn´t work with ¨tty /dev/pts/57¨? Was the 57 correct? ie you typed tty on a terminal and replaced 57 with whatever it supplies? The tty code has worked since 1999 so I´d not be suprised if it stopped working on a major change of the system. It´s possible it needs refreshing... .. or has this bug skewed off into a libtool problem now? jbb
Whenever I run the debugger inside of kdevelop, the tty number changes. I figure that the tty number has to do with the shell that it sometimes launches. I have tried it with and without launching a new terminal window, and I still get the shared library error. I have changed both my version of kdevelop from 2.1.3 to 3.0.3 and my version of redhat from 8.0 to fedora core 2 and I am just not sure where the problem is. However, when I run the same commands that kdevelop does, outside of kdevelop debugging window, it fails with the tty line and works without it. -Scott ---------------------------------------------------------------- Scott Shandler Graduate Student Biochemistry & Molecular BioPhysics University of Pennsylvania shandles@mail.med.upenn.edu Quoting John Birch <jbb@kdevelop.org>: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=83445 > > > > > ------- Additional Comments From jbb kdevelop org 2004-06-17 09:43 ------- > Scott, > > You said it didn´t work with ¨tty /dev/pts/57¨? Was the 57 correct? ie you > typed tty on a terminal and replaced 57 with whatever it supplies? > The tty code has worked since 1999 so I´d not be suprised if it stopped > working on a major change of the system. It´s possible it needs > refreshing... > > .. or has this bug skewed off into a libtool problem now? > > jbb >
> Whenever I run the debugger inside of kdevelop, the tty number changes. I > figure that the tty number has to do with the shell that it sometimes > launches. I am pretty sure this is the case. > I have tried it with and without launching a new terminal window, > and I still get the shared library error. Have you got the _same_ error with all versions (kdevelop, system)? Do you get the same error if you generate a new project from scratch? (using the wizard) > However, when I run the same > commands that kdevelop does, outside of kdevelop debugging window, it fails > with the tty line and works without it. * Do you use _identical_ lines - including "sh" and ".../libtool" or do you start from gdb? "/bin/sh -c /home/shandles/projects/tiger/libtool /usr/bin/gdb /home/shandles/projects/tiger/tiger/tiger -fullname -nx -quiet" * Do you get the _identical_ works/non works result? Or do you get different errors? * You get "(no debugging symbols found)... " before the tty command (so that cant be blamed on the tty command). Why? Does not tiger contain debug info? Or does it try to debug gdb itself?
I have installed the most recent version of gdb (6.1.1) from http://ftp.gnu.org/gnu/gdb/gdb-6.1.1.tar.gz, and debugging in kdevelop is possible again.
So upgrading to the suggested GDB version seemed to help somewhat, I can actually run the executable now in KDevelop through the however the framestack and breakpoints are not functioning properly. They appear to be disconnected from the rest of kdevelop. i'll continue to investigate.
So it appears as if kdevelop does not properly issue the file command to GDB, skipping all breakpoints as in the following transcript: Any ideas? /bin/sh -c /home/shandles/projects/tiger/libtool gdb /home/shandles/projects/tiger/tiger/tiger -fullname -nx -quiet (gdb) set edit off (gdb) set confirm off (no debugging symbols found)... Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) (gdb) (gdb) set print static-members on (gdb) tty /dev/pts/80 (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/shandles/projects/tiger/tiger (gdb) set args input/gb.in (gdb) break main.cpp:44 No symbol table is loaded. Use the "file" command. (gdb) run Stopped due to shared library event (gdb) break main.cpp:44 No source file named main.cpp. (gdb) continue Stopped due to shared library event (gdb) break main.cpp:44 No source file named main.cpp. (gdb) continue Stopped due to shared library event (gdb) break main.cpp:44 No source file named main.cpp. (gdb) continue Program continues normal execution, but without any breakpoints, and if I simulate a segfault, the kdevelop call stack is also disconnected from the kdevelop source code. (message on the bottom left corner of the screen, "No Source" -Scott
I have a similar problem, but here the debugged program is frozen and no debugger interaction from kdevelop is possible: It's gdb version gdb-6.2.1-2 from a SuSE 9.2, and the latest kdevelop from head. The application is a multithreaded Qt application with the latest public aviable qt version (qt-x11-free-3.3.3) gdb /home/drzoom/Entwicklung/ExactNode/bin/exactnode -fullname -nx -quiet (gdb) set edit off (gdb) set confirm off Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) (gdb) (gdb) set print static-members off (gdb) tty /dev/pts/4 (gdb) set width 0 (gdb) set height 0 (gdb) set stop-on 0 (gdb) handle SIG32 pass nostop noprint (gdb) handle SIG43 pass nostop noprint (gdb) set print asm-demangle off (gdb) set output-radix 16 (gdb) cd XXXXXXXXXXXXXXXXXX/bin (gdb) set args -e --name="primary" (gdb) break socketdevicebuffer.cpp:38 Breakpoint 1 at 0x8087e9d: file socketdevicebuffer.cpp, line 38. (gdb) run [Thread debugging using libthread_db enabled] warning: Unable to set global thread event mask: generic error (gdb) backtrace [New Thread 1089323520 (LWP 27934)] Any ideas? Tobias
the problem in comment #13 is different and probably needs a new bug filed for it. The rest of the problem seems Fedora specific and from what I can tell is fixed in Fedora Core 3. Please upgrade to FC3 and if it's still broken, please reopen.