Bug 83445

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.