Bugzilla – Full Text Bug Listing
| Summary: | some times the user cannot step for 5 seconds during fast stepping | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Dobrin Alexiev <dalexiev> | ||||||
| Component: | cdt-debug-dsf | Assignee: | Anton Leherbauer <aleherb+eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Pawel Piech <pawel.1.piech> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | aleherb+eclipse, pawel.1.piech | ||||||
| Version: | 7.0 | ||||||||
| Target Milestone: | 7.0.2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I think your analysis makes perfect sense and so does the suggested fix. I only wonder why the call to displaySource(eventtriggered==false) overrides the one with eventTriggered==true. Toni added this feature he may be able to comment on it better. Cheers, Pawel (In reply to comment #1) > I think your analysis makes perfect sense and so does the suggested fix. I > only wonder why the call to displaySource(eventtriggered==false) overrides the > one with eventTriggered==true. Toni added this feature he may be able to > comment on it better. Any source display request coming in after the other has higher priority, that's why any previous request is obsolete and can be canceled. We just need to make sure that doneStepping is called if necessary. With DSF-GDB I never get into this situation, except when a breakpoint is hit. In this case we receive two suspended events (one normal suspended event and a breakpoint-hit event which is also a suspended event). In this particular case it would be actually wrong to perform doneStepping() for the canceled job, because the latter should do it instead. I'll attach a patch. Created attachment 179101 [details]
Proposed fix
Could you try this patch if it works for you? Thanks.
Thanks you Tony. The fix works for me. With it I cannot reproduce the issue anymore. Is it possible to have the fix in both 7.0.x and 8.x? Targeted for 7.0.2. Thanks, again. Fixed in HEAD (8.0) and cdt_7_0 (7.0.2). Created attachment 182470 [details]
Follow-up fix
We found another case of this issue and this patch addresses it.
Committed the follow-up fix to HEAD and cdt_7_0. |
Build Identifier: Version: 3.6.0 DsfSourceDisplayAdapter.startDisplayJob() is called with eventTriggered = true. A DisplayJob() with eventTriggered = true is created and scheduled. Right after that DsfSourceDisplayAdapter.startDisplayJob() is called with eventTriggered = false. The previous DisplayJob is canceled :fRunningDisplayJob.cancel(); but its run() never had chance to execute, therefore never call doneStepping(fResult.getDmc()); That will prevent StepController to allow further stepping. I did simple experimenting by adding these two lines of code just before: fRunningDisplayJob.cancel(); if( fRunningDisplayJob.fEventTriggered) doneStepping(fRunningDisplayJob.fResult.getDmc()); After adding these two lines the issue is gone! I don’t understand DsfSourceDisplayAdapter 100% yet, but I wanted to check with you if this is correct use case for the class. If a display job is to be canceled should we make sure that doneStepping is called on its behalf. Or may be if the display job is preempted by another display job we somehow transfer the doneStepping responsibility. Or may be somehow the use case I’m describing should be prevented in another place. Reproducible: Always