Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 327227

Summary:

Unreliable GDB termination

Product:

[Tools] CDT

Reporter:

Vladimir Prus <vladimir.prus>

Component:

cdt-debug-dsf-gdb

Assignee:

Marc Khouzam <marc.khouzam>

Status:

RESOLVED FIXED

QA Contact:

Marc Khouzam <marc.khouzam>

Severity:

normal

Priority:

CC:

pawel.1.piech, ted

Version:

8.0

Target Milestone:

8.0

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
The patch to make the bug more reproducable	cdtdoug: iplog-

Description Vladimir Prus

2010-10-07 09:05:48 EDT

Build Identifier: 

Apply the attached patch. It makes RxThread to sleep for a second when it processes *stopped,reason="exited-normally" to simulate a realistic situation where GDB takes a split second to thing between =thread-group-exited and *stopped,reason="exited-normally".

Run a hello-world program under DSF with this patch. When it stops in main, resume.

Excepted result: program exits, launch is fully terminated.
Observed result: launch is almost terminated, gdb is left running.

The reason it happens is that termination of GDB is handled inside GDBControl_7_0.eventDispatched(ContainerExitedDMEevent), which calls
isConnected which calls MIInferiorProcess.getState and checks if it's
"terminated". However, the state is set to terminated when processing
"*stopped" response. Normally, it works because dispatching of
ContainerExitedDMEevent involves more DsfRunnable instances. However, if *stopped is a little bit late, the state of MIInferior is not yet TERMINATED,
and therefore GDB is not terminated as well.

At present, I don't have a viable approach to fixing this, and would appreciate some guidance.

Reproducible: Always

Comment 1 Vladimir Prus

2010-10-07 09:06:18 EDT

Created attachment 180420 [details]
The patch to make the bug more reproducable

Comment 2 Marc Khouzam

2010-11-12 10:05:19 EST

I think the problem is that the concept of inferior was not properly updated (by me) to deal with Multi-process.  If you run the same test with gdb 6.8, you will not see the problem.  The reason is that GDBControl.eventDispatched(ContainerExitedDMEvent) blindly terminates GDB since it only deals with a single process.  

If I remember correctly, it is because GDBControl_7_0.eventDispatched(ContainerExitedDMEvent) deals with multi-process, that we have to call isConnected() to make sure that the ContainerExitedDMEvent is for the last process.

Thing is, right now, multi-process only works for remote-attach sessions, so I think the call to isConnect() is unnecessary.

Once we properly handle multi-process on Linux, we will have to deal with this better.  Until then, this may be a good workaround for you.

Comment 3 Marc Khouzam

2011-03-04 13:31:18 EST

Fixed by Bug 338319.

Volodya, with HEAD of March 2nd I expect this problem to be gone.  I've tried with your attach patch which allows to reproduce and I can't see it anymore.

If I'm wrong, feel free to re-open.

Comment 4 Marc Khouzam

2011-05-16 10:36:09 EDT

Comment on attachment 180420 [details]
The patch to make the bug more reproducable

This patch was just a test patch and was never committed.