Bugzilla – Full Text Bug Listing
| Summary: | Fails to interrupt debugger and manage breakpoints when debugger is running | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | xingyun <cx186000> |
| Component: | cdt-debug-dsf-gdb | Assignee: | Project Inbox <cdt-debug-dsf-gdb-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | Marc Khouzam <marc.khouzam> |
| Severity: | critical | ||
| Priority: | P3 | CC: | cdtdoug, pawel.1.piech |
| Version: | 7.0.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Attachments: | |||
Created attachment 188743 [details]
gdb trace for adding a breakpoint, the correct condition
This file shows the gdb trace when it's ok to add a breakpoint when debugger is running.
It is fine to add a breakpoint when the previous execution is fully finished.
Created attachment 188744 [details]
Prepare to reproduce the bug: debugger is running with breakpoints already installed.
1. Breakpoints are added when debugger is suspended.
2. Resume the debugger
3. Next step should click the "Remote all breakpoints" in the Breakpoints View
Created attachment 188745 [details]
delete breakpoints and this is the gdb trace
Created attachment 188746 [details]
debugger is running while the backend is suspended
1. Clear the console
2. Interrupt the debugger
3. Console shows some "-exec-continue" commands
4. Debugger is out-of-sync with the backend
The content of attachment 188746 [details] has been deleted by Denis Roy <denis.roy@eclipse.org> who provided the following reason: As requested by the submitter, via webmaster inbox 2011-02-11 15:51 The token used to delete this attachment was generated at 2011-02-11 16:09:23 EST. The content of attachment 188743 [details] has been deleted by Denis Roy <denis.roy@eclipse.org> who provided the following reason: As requested by the submitter, via webmaster inbox 2011-02-11 15:51 The token used to delete this attachment was generated at 2011-02-11 16:10:02 EST. The content of attachment 188744 [details] has been deleted by Denis Roy <denis.roy@eclipse.org> who provided the following reason: As requested by the submitter, via webmaster inbox 2011-02-11 15:51 The token used to delete this attachment was generated at 2011-02-11 16:10:09 EST. The content of attachment 188745 [details] has been deleted by Denis Roy <denis.roy@eclipse.org> who provided the following reason: As requested by the submitter, via webmaster inbox 2011-02-11 15:51 The token used to delete this attachment was generated at 2011-02-11 16:10:17 EST. This is the same issue as Bug 337893. The problem is that the code of IMIRunControl#executeWithTargetAvailable is not prepared to be called multiple overlapping times. But it really must handle that case. Confirmed as duplicated with Bug 337893 *** This bug has been marked as a duplicate of bug 337893 *** |
Build Identifier: SLES 10 General: It would failt to interrupt debugger to manage breakpoints when debugger is running. Envrionment CDT 7.0.1, Eclipse Helios 3.6.1 SR2 A customized version of GDB use DSF debugger, not CDI Eclipse is deployed on a Win32 system, it's debugging a remote Linux VM The protocol is SSH Reproduce the bug: 1. Launch DSF debugger to attach to a remote target 2. Resume the debugger. 3. Debugger is running. 4. Add a breakpoint, everything is fine. 5. Add another breakpoint, still fine. 6. Add several breakpoints, the operation fails or: 1. Add 10 breakpoints when debugger is suspended 2. Resume the debugger 3. In breakpoints view, click "Remove all breakpoints" button 4. Debugger crashes My Observation: In source code: MIRunControl: executeWithTargetAvailable During runtime, we take adding a breakpoint for example, this method will be invoked twice. The first time, the steps to be executed should be: IsTargetAvailableStep MakeTargetAvailableStep GDBBreakpoints (-break-insert command) RestoreTargetStateStep The second time, the 4 steps should be: IsTargetAvailableStep MakeTargetAvailableStep GDBBreakpoints (-break-enable command) RestoreTargetStateStep Those steps will check some status and to avoid sending duplicate commands. However, this runs to a mass when there are lots of requests for it. And it does take some time to finish adding a breakpoint in such condition. Debugger crashes: The steps are executed "sliently", the result is GUI is in running state while the backend is suspended. All debug buttons are disabled. We have no choice to shutdown the debugger Other resources: Other relative bugs are recorded: https://bugs.eclipse.org/bugs/show_bug.cgi?id=305178 It's quite similar a case but i can not find the useful information in comments Attachments: Will be uploaded later Reproducible: Always Steps to Reproduce: General: It would failt to interrupt debugger to manage breakpoints when debugger is running. Envrionment CDT 7.0.1, Eclipse Helios 3.6.1 SR2 A customized version of GDB use DSF debugger, not CDI Eclipse is deployed on a Win32 system, it's debugging a remote Linux VM The protocol is SSH Reproduce the bug: 1. Launch DSF debugger to attach to a remote target 2. Resume the debugger. 3. Debugger is running. 4. Add a breakpoint, everything is fine. 5. Add another breakpoint, still fine. 6. Add several breakpoints, the operation fails or: 1. Add 10 breakpoints when debugger is suspended 2. Resume the debugger 3. In breakpoints view, click "Remove all breakpoints" button 4. Debugger crashes