Bugzilla – Full Text Bug Listing
| Summary: | [disassembly] maximizing then minimizing causes debug stack view event to force return to PC | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Kirk Beitz <kirk.beitz> | ||||||
| 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, ken.ryall, pawel.1.piech | ||||||
| Version: | 7.0 | ||||||||
| Target Milestone: | 8.0 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 178303 [details]
Fix
The solution is to listen to debug context changes instead of selection changes in the debug view.
toni ++ i've applied this patch, and it solves the problem i was seeing. thanks Thanks for verifying. Committed to HEAD. *** cdt cvs genie on behalf of aleherbau *** Bug 324613 - [disassembly] maximizing then minimizing causes debug stack view event to force return to PC [*] DisassemblyView.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/internal/ui/disassembly/DisassemblyView.java?root=Tools_Project&r1=1.4&r2=1.5 |
Created attachment 178291 [details] non-working patch attempting to show the direction i started in attempting to fix this problem steps to reproduce: 1) scroll away from the PC in the disassembly view 2) double-click the tab for the disassembly view to maximize 3) double-click after it maximizes ACTUAL RESULT: it returns to the PC location of that frame EXPECTED RESULT: minimize without changing the scroll location of the view root cause: the re-exposure of the debug-stack view causes an event that forces a pending-PC update. i don't have a working solution. in the interest of what i thought should have solved the problem, i'm attaching the patch of what i changed to try to prevent the pending-PC updates. however, the biggest negative side-effect is that fFrameAddress doesn't always get set properly in all cases using this patch. my sense is that if fFrameAddress were to get properly set directly from a call to updatePC(), then it wouldn't be necessary to rely entirely on updateVisibleArea() to make the calls that result in fFrameAddress to get properly set. i'm just not entirely certain where to make such a call. in any case, i'm hoping that there is agreement regarding the expected result, that the problem is easily reproduced, and that the attempt i made to solve the problem might lead someone else familiar with the code to have a good idea of what to do in order to prevent this boomerang effect.