Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325063

Summary: [disassembly] view occasionally accepts no further scrolling/PC changes with unhandled assert
Product: [Tools] CDT Reporter: Kirk Beitz <kirk.beitz>
Component: cdt-debug-dsfAssignee: 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.1Flags: aleherb+eclipse: review+
Target Milestone: 7.0.2   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
add code to report error without unhandled assert aleherb+eclipse: iplog-

Description Kirk Beitz CLA 2010-09-12 21:49:52 EDT 
Created attachment 178711 [details]
add code to report error without unhandled assert

sometimes the disassembly view gets into a state where scrolling will not go get more input and PC changes don't cause the PC marker to change.

the error console shows an unhandled assertion from DisassemblyBackendDsf#retrieveFrameAddressInSessionThread().

the best way to attempt to reproduce this appears to be to quickly change frames when the disassembly view is first being populated.  it is admittedly hard to reproduce.

the attached patch will log an error to the error console without killing the disassembly view.  admittedly, it doesn't solve the problem of what to do with the mismatch between the requested level and the fTargetFrameContext.  at the very least, continued stepping or debugger operation no longer requires the user to close the Disassembly view and re-open it.

will continue to try to come up with the best solution about what to do aside from reporting the error, and open to suggestions about how to recover (i.e. perhaps best to force the fTargetFrameContext to be set to the same level, or perhaps just better to return and ignore).
Comment 1 Anton Leherbauer CLA 2010-09-15 03:41:28 EDT 
Actually, I think the assert is wrong.  It is to be expected that the frame context can change while a query for frame information has been scheduled.  I would not even bother to log that condition.  Simply returning should do it, because another query should already be scheduled for the new context.
Comment 2 Kirk Beitz CLA 2010-09-15 03:50:27 EDT 
(In reply to comment #1)
> Actually, I think the assert is wrong.  It is to be expected that the frame
> context can change while a query for frame information has been scheduled.  I
> would not even bother to log that condition.  Simply returning should do it,
> because another query should already be scheduled for the new context.

i'm perfectly fine with not logging it.

do you want another patch?  or am i correct in presuming you can just delete the assert yourself and commit without further input from me?
Comment 3 Anton Leherbauer CLA 2010-09-15 03:56:19 EDT 
(In reply to comment #2)
> do you want another patch?  or am i correct in presuming you can just delete
> the assert yourself and commit without further input from me?

No further input necessary, I just want to test it first.
Comment 4 Anton Leherbauer CLA 2010-09-15 07:07:36 EDT 
Fixed in HEAD.
I had to extend the changes a little to make quick navigation between different frames work reliably.
Comment 6 Kirk Beitz CLA 2010-09-15 12:55:02 EDT 
thanks, toni.

what are the chances that this unhandled assertion preventer can go onto CDT_7_0 now?  if not high, what about after CDT 7.0.1 ships so it can be there for 7.0.2?
Comment 7 Anton Leherbauer CLA 2010-09-16 02:48:41 EDT 
(In reply to comment #6)
> what are the chances that this unhandled assertion preventer can go onto
> CDT_7_0 now?  if not high, what about after CDT 7.0.1 ships so it can be there
> for 7.0.2?

7.0.2 should be OK.  I don't think this qualifies for a respin of 7.0.1.
Comment 8 Anton Leherbauer CLA 2010-09-28 08:23:26 EDT 
Targeting 7.0.2.
Comment 10 Anton Leherbauer CLA 2010-09-29 08:54:49 EDT 
Fixed also in 7.0.2.