Bug 435727 - eclipse suspend makes gdb exit when remote debugging over ssh
Summary: eclipse suspend makes gdb exit when remote debugging over ssh
Alias: None
Product: Fedora
Classification: Fedora
Component: eclipse-cdt
Version: 8
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnston
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-03 16:07 UTC by Wilfried Philips
Modified: 2008-11-26 19:48 UTC (History)
3 users (show)

Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-26 19:48:25 UTC

Attachments (Terms of Use)
eclipse console output when connecting through ssh (4.18 KB, text/plain)
2008-03-03 16:07 UTC, Wilfried Philips
no flags Details
eclipse console output when "connecting" using bash rather than "ssh" (5.59 KB, text/plain)
2008-03-03 16:08 UTC, Wilfried Philips
no flags Details
run the gdb-over-ssh remote debugging from teh command line (displaying correct behaviour) (502 bytes, text/plain)
2008-03-03 16:09 UTC, Wilfried Philips
no flags Details

System ID Priority Status Summary Last Updated
Eclipse Project 221410 None None None Never

Description Wilfried Philips 2008-03-03 16:07:28 UTC
Description of problem:

I am trying to perform remote debugging using eclipse and gdb.
I run eclipse on a FC8 linux computer with the latest updates 
(one host system is an acer travelmate; the other an and desktop;
the problem does not depend on the host platform).

The client system is a powerpc 405 set-top box running a minimal 
busybox=based version of linux. With gdb and ddd I could debug an application
on this system by specifying 
ddd --debugger 'ssh -t client.telin /tmp/command'
were /tmp/command contains a command line that starts the program to
debug under gdb.

I now follow a similar approach to debug the client system from 
eclipse and it basically works very well, except for one showstopper:
When I select "suspend" from the menu, the program is not suspended,
but gdb exists. In information scattered around the internet, I have 
seen related reports, but never exactly equal.

To simplify testing of the problem, I switched to debugging the following
helloworld.c program, which is debugged (using ssh to simulate 
remote debugging) and run on the same system.

int main(void) {
	printf("Hello World!!!");
	printf("hello done");
	return 0;

Relevant settings are:

-connect process input_output to a terminal
-gdb debugger: /home/philips/workspace/hello/hellodebug
-gdb command set: stanadard linux (also tried other settings)
-protocol mi (tried various combinations)
-verbose console mode
-Allocate console (necessary for input)

ssh -t eltodo.telin /home/philips/workspace/hello/hellodebug1
#bash -c /home/philips/workspace/hello/hellodebug1

cd /home/philips/workspace/hello; 
gdb  -q -nw -i mi  --cd=/home/philips/workspace/hello --command=.gdbinit

It is not 100% clear if gdb is at fault or eclipse, but I am sure 
that the problem is related to the communication between both, as the
testcases below illustrate. Also, based on the test cases, 
I think it is more likely that eclipse is at fault rather than gdb.

I hope that this issue can be resolved. I am willing to do 
some more experiments.

Version-Release number of selected component (if applicable):

#rpm -q eclipse-cdt gdb

How reproducible:

Steps to Reproduce:
1. start eclipse. 

2. Run debug with the above settings. Step twice with F6 
until sleep line activates. 

3. Use "suspend" in the debug menu. 

Actual results:

gdb exits. See console.ssh.log

Expected results:
gdb should not exit, allowing me to debug the program

Additional info:

With a slightly modified hellodebug script **all works as expected**
(see console.bash.log; which ends just after I select "suspend" from the menu):
-eclipse displays a stack trace. Thread 0 has a message next to
it "suspended: signal 'SIGINT' receved'"). 
-I can continue to run the program.

The only modification is that I replace "ssh -t  eltodo.telin" with
"bash -c". Of course this is totally useless for remote debugging but it 
illustrates that the problem is in the communication between eclipse 
and the (remote) gdb.

As another experiment, I ran hellodebug (ssh version) from the commandline
(see commandline.log).
I started hellodebug and then typed
b main

All worked as expected.

In conclusion: when eclipse is not involved, all works as expected.
Otherwise, I have problems.

Note: I do not want to use gdbserver because the settop box
application I am debugging is multithreaded and gdbserver is too 
limited for that.

Comment 1 Wilfried Philips 2008-03-03 16:07:28 UTC
Created attachment 296623 [details]
eclipse console output when connecting through ssh

Comment 2 Wilfried Philips 2008-03-03 16:08:20 UTC
Created attachment 296624 [details]
eclipse console output when "connecting" using bash rather than "ssh"

Comment 3 Wilfried Philips 2008-03-03 16:09:46 UTC
Created attachment 296627 [details]
run the gdb-over-ssh remote debugging from teh command line (displaying correct behaviour)

Comment 4 Andrew Overholt 2008-03-03 16:11:31 UTC
Jeff, please take a look at this.

Comment 5 Jeff Johnston 2008-03-04 19:50:55 UTC
I was able to reproduce the problem in Fedora, however, with upstream
Eclipse downloaded plus the CDT 4.0.1 installed directly via Update Manager, the
test also fails and gdb exits.  This means the bug is upstream.  Please open a
bug against upstream CDT and when you have done so, please close this bug as
UPSTREAM and add the Eclipse bug number in the External bug references section

Comment 6 Bug Zapper 2008-11-26 10:00:09 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 7 Jon Stanley 2008-11-26 17:37:27 UTC
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report.

If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against.

Thanks for the report!

Comment 8 Andrew Overholt 2008-11-26 18:23:32 UTC
It doesn't look like  Wilfried got a chance to open a bug upstream.  Jeff, can you please do it?

Comment 9 Jeff Johnston 2008-11-26 19:48:25 UTC
(In reply to comment #8)
> It doesn't look like  Wilfried got a chance to open a bug upstream.  Jeff, can
> you please do it?

He already did so.  See the External bugs section above.

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