Bugzilla – Full Text Bug Listing
| Summary: | Unresolved breakpoint freezes application | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Axel Mueller <aegges> | ||||||||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||||||||
| Severity: | critical | ||||||||||||||
| Priority: | P3 | CC: | pawel.1.piech, vkrevs | ||||||||||||
| Version: | 7.0 | Flags: | pawel.1.piech:
review+
|
||||||||||||
| Target Milestone: | 7.0 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 170255 [details]
hello world project
Here is a simple Hello World project to demonstrate the bug.
1) Debug the application. It has an endless loop.
2) set a breakpoint in HelloWorld.cpp at line 17 inside the loop
=> the debugger will stop the app correctly
3) remove breakpoint and resume
4) set a breakpoint in file unused.cpp (this file is not included in the build!)
5) you will see an error message in the gdb traces console
6) try again to set a breakpoint in HelloWorld.cpp at line 17 inside the loop
=> the debugger will *not* the app
gdb traces shows "Quit"
Created attachment 170325 [details]
Prototype fix
I have to run more tests, but I thought Axel might want to try this out.
Created attachment 170392 [details]
Fix for all-stop mode
This is the fix that covers all-stop mode. I will code the same solution for the non-stop mode, but I wanted to post this now to hopefully get a review.
This fix has an API change which removes the RestoreTargetStateStep and creates a restoreTargetState() method. Note that RestoreTargetStateStep was added in 7.0 anyway. I could achieve the same thing using the RestoreTargetStateStep class inside its own Sequence, but it makes things more obscure. Let me know if you prefer to avoid the API change.
Pawel, this fix is really late in the cycle so if you could have a glance, I'd feel better. I know you had warned me about not cleaning up properly here, but I missed that case :-( Created attachment 170399 [details]
Simpler fix.
This fix adds a rollBack implementation to the MakeTargetAvailaleStep, rather than adding more state variables in the class. I didn't the fix it's just an implementation suggestion.
One more observation is that this sequence should be somehow protected so that other run control operations don't interrupt it. This would probably be a wider-scope change.
(In reply to comment #5) > Created an attachment (id=170399) [details] > Simpler fix. > > This fix adds a rollBack implementation to the MakeTargetAvailaleStep, rather > than adding more state variables in the class. I didn't the fix it's just an > implementation suggestion. So nice! I never used the rollBack mechanism before. Very elegant. I'll code the full patch. Thanks! > One more observation is that this sequence should be somehow protected so that > other run control operations don't interrupt it. This would probably be a > wider-scope change. You're right. I'll open a separate bug. Created attachment 170410 [details]
Pawel's patch including non-stop and JUnit test
Here is the final patch based on Pawel's nice suggestion. Tested and JUnit tested successfully. Committed to HEAD. Pawel, can you review? (and thanks!) *** cdt cvs genie on behalf of mkhouzam *** Bug 314628: Always restore the target state even if a failure has happened. [*] MIBreakpointsTest.java 1.12 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/src/org/eclipse/cdt/tests/dsf/gdb/tests/MIBreakpointsTest.java?root=Tools_Project&r1=1.11&r2=1.12 [*] GDBRunControl_7_0_NS.java 1.23 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBRunControl_7_0_NS.java?root=Tools_Project&r1=1.22&r2=1.23 [*] MIRunControl.java 1.27 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIRunControl.java?root=Tools_Project&r1=1.26&r2=1.27 [*] IMIRunControl.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/IMIRunControl.java?root=Tools_Project&r1=1.5&r2=1.6 (In reply to comment #5) > One more observation is that this sequence should be somehow protected so that > other run control operations don't interrupt it. This would probably be a > wider-scope change. I've opened Bug 314947 about this. Looks good. *** Bug 318312 has been marked as a duplicate of this bug. *** |
Build Identifier: CDT 7.0.0.201005241228 I have a single project with a large code base for a number of applications. The applications share some common code and are build via Makefiles from our own build system. It is a common scenario that I debug several applications in one session (server and client app). I could set a breakpoint where ever and whenever I wanted. That was never a problem with the CDI debug interface. This changed when I switched to DSF using CDT 7.0 (nightly build). Whenever I set a breakpoint that is in a source file not included in an application that is currently running that application will completely freeze. Reproducible: Always Steps to Reproduce: Here is the gdb traces output: .... 562,822 *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={add\ r="0xf7fdf430",func="__kernel_vsyscall",args=[]},thread-id="1",stopped-threads="all" 562,825 10-break-insert /home/amueller/sources/UniDecod.cpp:252 562,826 (gdb) ..process list... 562,849 (gdb) # for a dozen seconds or minutes(!) nothing happens!!! cpu load of gdb is 100% 752,775 10^error,msg="No source file named /home/amueller/sources/UniDecod.cpp." 752,775 (gdb) The app is still unresponsive and I cannot control gdb anymore (e.g. suspend). I have to kill the application (incl. gdb). Using Absolute File Path for source lookup will prevent high cpu load (see bug #302969) but application is still unresponsive after setting the breakpoint. The problem does not occur if the breakpoint was set *before* the start of the application. But that's not a bearable workaround. I have marked this bug as critical because my application that is debugged must be killed and all data will be lost.