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

Bug 352998

Summary: [remote][attach] Cannot do a remote-attach session with GDB7.2 and CDT8.0
Product: [Tools] CDT Reporter: Marc Khouzam <marc.khouzam>
Component: cdt-debug-dsf-gdbAssignee: Marc Khouzam <marc.khouzam>
Status: RESOLVED FIXED QA Contact: Marc Khouzam <marc.khouzam>
Severity: normal    
Priority: P3 CC: cdtdoug, pawel.1.piech
Version: 8.0Flags: marc.khouzam: review? (pawel.1.piech)
Target Milestone: 8.0.1   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Fix for master
marc.khouzam: iplog-
Update on fix for master
marc.khouzam: iplog-
Fix for 8_0 branch
marc.khouzam: iplog-
Yet another fix for master
marc.khouzam: iplog-
Matching fix for cdt_8_0 marc.khouzam: iplog-

Description Marc Khouzam CLA 2011-07-25 08:23:22 EDT 
GDB 7.2 has a bug which causes a gdbserver crash if we set the binary after we have connected to the target.  With the handling of multi-process, the logic we now use in CDT for a remote-attach is:

1- connect to the target
2- ask user which binary to debug
3- set the binary in GDB

This cause the gdbserver crash and we cannot do any remote-attach debugging.  Note that before our multi-process support, we would set the binary before connecting to the target, since we took the binary from the launch config.  This would not cause the GDB 7.2 bug.  

I had asked if this would bug be fixed in GDB 7.2.1 on March 4th, 2011:
http://sourceware.org/ml/gdb-patches/2011-03/msg00327.html
The fix was put in on March 8th, 2011:
http://sourceware.org/ml/gdb-patches/2011-03/msg00531.html

The release of GDB 7.2.1 has been "Imminent (as of 2010-12-16)" (copied from GDB's schedule page today), so I really thought it would be release before CDT 8.0 was released.  This did not happen, and GDB 7.2.1 is still not released.  So, now we have a CDT 8.0 that cannot do remote-attach debugging with GDB 7.2.

The workaround would be to tell users to use GDB 7.1 or earlier.  However, that won't allow for a multi-process session.  So, to get multi-process remote-attach, the user would have to build his own GDB after applying the fix to the bug.  Which is not a viable solution.

So, I will workaround the bug in CDT.

To reproduce the bug:
> gdbserver.7.2 --multi :9999
> gdb.7.2
target extended-remote :9999
file <anyBinary>
=> gdbserver CRASH
Comment 1 Marc Khouzam CLA 2011-07-25 08:34:50 EDT 
I tried all kinds of combinations (I tried to be exhaustive) to workaround the GDB bug without limiting the functionality we offer.  Below are the list of things I tried unsuccessfully.

BROKEN CASES

> gdb.7.2
target extended-remote :9999
file <anyBinary>
=>gdbserver CRASH

> gdb.7.2
file <anyBinary>
target extended-remote :9999
file <anyBinary>
=>gdbserver CRASH

> gdb.7.2
target extended-remote :9999
add-inferior
inferior 2
file <anyBinary>
=>gdbserver CRASH

> gdb.7.2
file <anyBinary>
target extended-remote :9999
add-inferior
inferior 2
file <anyBinary>
=>gdbserver CRASH

> gdb.7.2
file <anyBinary>
target extended-remote :9999
add-inferior
inferior 2
remove-inferior 1
NOT ALLOWED

> gdb.7.2
target extended-remote :9999
add-inferior
inferior 2
remove-inferior 1
file <anyBinary>
=>gdbserver CRASH

> gdb.7.2
add-inferior
inferior 2
remove-inferior 1
target extended-remote :9999
file <anyBinary>
=>gdbserver CRASH

The first working scenario I could find was to revert to how we previously handled the situation:

WORKING SCENARIO
> gdb.7.2
file <anyBinary>
target extended-remote :9999
attach <pid>

The above has the problem that the user must put a binary in the launch and must choose the binary that was put in the launch when attaching.  This is a limitation on what we actually could offer if GDB didn't have the bug.  What we can offer is that the user does not specify anything binary in the launch, and choose the binary once the debug session is started.

To avoid that limitation, we would need to know what binary the user wants, before connecting to the target.  This is not actually possible, since we need to connect to the target to give a list of available processes to the user to choose from.  However, we can still make it happen by:
1- connecting to the target
2- finding out the binary from the user
3- disconnecting from the target
4- setting the binary
5- connecting again.

This translates to:

> gdb.7.2
target extended-remote :9999
<prompt user for binary after showing a list of running procs>
disconnect
file <anyBinary>
target extended-remote :9999
attach <pid>
Comment 2 Marc Khouzam CLA 2011-07-25 09:16:42 EDT 
Created attachment 200278 [details]
Fix for master

This patch disconnects from the target, sets the binary and then reconnects, when using GDB 7.2.  I already put it a class for GDB 7.2.1 to turn off this workaround.

Committed to master.
Comment 3 Marc Khouzam CLA 2011-07-25 09:46:24 EDT 
Created attachment 200279 [details]
Update on fix for master

I found a small bug in my previous fix.

Committed to master.
Comment 4 Marc Khouzam CLA 2011-07-25 09:53:40 EDT 
Created attachment 200280 [details]
Fix for 8_0 branch

This patch is the fix for the 8_0 branch.
To avoid adding APIs, I made the following changes:

1- no new GDBProcesses_7_2_1 class.  This means that for GDB >= 7.2.1, even though the workaround is not needed, it will be used.   This is not going to break anything, so I felt it was ok (for the maintenance branch only)
2- put the new MITargetDisconnect class in an internal package: org.eclipse.cdt.dsf.gdb.internal.commands.

Committed to 8_0
Comment 5 Marc Khouzam CLA 2011-07-25 09:55:12 EDT 
Fixed.
Pawel, can you review?
Comment 6 CDT Genie CLA 2011-07-25 10:18:46 EDT 
*** cdt git genie on behalf of 352998 ***

    Bug 352998: [remote][attach] Cannot do a remote-attach session with GDB7.2 and CDT8.0

[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=142ab815932926dd35d90d1f15836f2a66dd0e10
Comment 7 CDT Genie CLA 2011-07-25 10:18:48 EDT 
*** cdt git genie on behalf of 352998 ***

    Bug 352998: [remote][attach] Cannot do a remote-attach session with GDB7.2 and CDT8.0

[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=c5c97a7b3b5afb7ed7b3b681b5ccecb4f4622bbe
Comment 8 CDT Genie CLA 2011-07-25 10:18:50 EDT 
*** cdt git genie on behalf of 352998 ***

    Bug 352998: [remote][attach] Cannot do a remote-attach session with GDB7.2 and CDT8.0

[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=0c43bc15c792144387286d91b5e5bb87b685a574
Comment 9 Marc Khouzam CLA 2011-07-25 11:56:36 EDT 
Created attachment 200292 [details]
Yet another fix for master

I realized that it is possible that the attach sequence fail before we reconnect to the target, which would leave the debug session in an invalid state.  To trigger this:

1- start a remote-attach session
2- attach to a process that is not specified in the launch (will trigger a prompt)
3- put an invalid path to cause GDB to reject the command to set the binary
=> we abort the attach operation after having disconnected from the target, and without reconnecting.

This patch reconnects to the target even in the case of a failure.
Committed to master.

I'll need the same fix for 8_0
Comment 10 CDT Genie CLA 2011-07-25 12:18:45 EDT 
*** cdt git genie on behalf of 352998 ***

    Bug 352998: [remote][attach] Cannot do a remote-attach session with GDB7.2 and CDT8.0

[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=579f5aa0ec4d299d18af50f0af7313aa64b4ecdc
Comment 11 Marc Khouzam CLA 2011-07-25 12:42:02 EDT 
Created attachment 200295 [details]
Matching fix for cdt_8_0

This is the matching fix for cdt_8_0 to handle an invalid binary path.

Committed
Comment 12 CDT Genie CLA 2011-07-25 13:18:45 EDT 
*** cdt git genie on behalf of 352998 ***

    Bug 352998: [remote][attach] Cannot do a remote-attach session with GDB7.2 and CDT8.0

[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=0d7bc691d2b6c409e8c550278f88894ea492683c
Comment 13 Marc Khouzam CLA 2011-07-26 14:59:09 EDT 
I noticed that the gdbserver crash does not only happen for the very first attach, but for any attach that happens when no other processes are attached to.  So, even after the fix I committed the crash can happen by doing this:

1- connect to the target
2- attach to a process
3- detach from the process using the 'disconnect' button (there are no more processes attached to in the session)
4- attach to a process
=> gdbserver crash
Comment 14 Marc Khouzam CLA 2011-07-28 10:10:23 EDT 
(In reply to comment #13)
> I noticed that the gdbserver crash does not only happen for the very first
> attach, but for any attach that happens when no other processes are attached
> to.  So, even after the fix I committed the crash can happen by doing this:
> 
> 1- connect to the target
> 2- attach to a process
> 3- detach from the process using the 'disconnect' button (there are no more
> processes attached to in the session)
> 4- attach to a process
> => gdbserver crash

This gdb bug has been fixed for the upcoming release of GDB 7.2.1.  The workaround of this particular set of steps, is not to detach from the last process until we attach to the next one.

Also, this cannot happen if the user has set the preference to kill GDB once the last process is detached from.

So, I don't feel it is worth it to fix this rare case since it probably won't occur often and has a workaround, and will disappear once people move to GDB 7.2.1.