Community
Participate
Working Groups
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
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>
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.
Created attachment 200279 [details] Update on fix for master I found a small bug in my previous fix. Committed to master.
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
Fixed. Pawel, can you review?
*** 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
*** 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
*** 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
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
*** 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
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
*** 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
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
(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.
