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

Bug 311380

Summary: Interrupting target can leave Debug view in awkward state
Product: [Tools] CDT Reporter: John Cortell <john.cortell>
Component: cdt-debug-dsf-gdbAssignee: John Cortell <john.cortell>
Status: RESOLVED FIXED QA Contact: Marc Khouzam <marc.khouzam>
Severity: normal    
Priority: P3 CC: pawel.1.piech
Version: 7.0Flags: marc.khouzam: review+
Target Milestone: 7.0   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
gdb trace
none
Screenshot showing the problem
none
Fix
john.cortell: iplog-
Screenshot showing behavior after patch
none
Updated patch based on Marc's review john.cortell: iplog-

Description John Cortell CLA 2010-05-03 10:52:43 EDT 
The attached screenshot shows what I'm seeing when interrupting MinGW 6.8 GDB in a standard (created process) DSF session. 

The problem seems to be a gdb one, but we can and should deal with it better. We ask gdb for the stack depth and it responds with an error saying it can't access memory at some address. Thing is, if we limit the request to one frame, the command succeeds. So, the workaround can be that whenever the stack depth request fails, to make a subsequent request with a limit of 1. The same issue happens later when actually asking for the frames. We need to ask for a single frame--the topmost one. 

I've attached the gdb trace. Search on "Cannot access memory" to see the failing command. This is the activity that happens after hitting the suspend button.
Comment 1 John Cortell CLA 2010-05-03 10:53:10 EDT 
Created attachment 166784 [details]
gdb trace
Comment 2 John Cortell CLA 2010-05-03 10:53:40 EDT 
Created attachment 166785 [details]
Screenshot  showing the problem
Comment 3 John Cortell CLA 2010-05-03 10:55:44 EDT 
Created attachment 166786 [details]
Fix
Comment 4 John Cortell CLA 2010-05-03 10:55:58 EDT 
Marc, please review.
Comment 5 John Cortell CLA 2010-05-03 11:04:11 EDT 
Created attachment 166789 [details]
Screenshot showing behavior after patch
Comment 6 Marc Khouzam CLA 2010-05-03 12:42:59 EDT 
Funny, I had to deal with a similar error for Tracepoints.  Weird that gdb does not return things properly for a case where the full data should be available.

- I think the check in getStackDepth should be maxDepth != 1 instead of maxDepth > 1.  A max depth of 0 will trigger a -stack-info-depth without any params, which request the full depth.  This will happen if you turn off the "Limit number of stack frame preference".  Pref->Run/Debug->View performance.

- from comments I got from the gdb experts for tracepoints, when the call -stack-info-depth fails for one depth, it could succeed for a lesser depth which need not be 1.  Pedro had suggested a divide a conquer algo to try to figure out the max depth e.g., when 11 fails, try 5, when it succeeds, try 7, if it succeeds try 9, when it fails try 8.  I thought this was too complicated and I also resorted to a depth of 1 in those cases, with the hope that newer GDBs won't have this problem.  After seeing your nice recursive call to getStackDepth() it made me think that we could try to do better than a depth of 1 by recursively calling it with maxDepth - 1.  But that could cause 10 calls to -stack-info-depth, so if you find this too much, we could call recursively with maxDepth/2.  To be honest, I'm fine with defaulting to 1 in this case, but I wanted you to know all the details.

- if you fix getStackDepth, do you still need to modify getFrameData()?  If getDepth() returns a proper depth, I think getFrameData will only ask for frames in that depth range.  If you do, then I think the change you made only makes sense in the case where miFrameDmc.fLevel == 0.  Also, you can probably call the method getTopFrame()
Comment 7 John Cortell CLA 2010-05-03 14:22:45 EDT 
(In reply to comment #6)
> Funny, I had to deal with a similar error for Tracepoints.  Weird that gdb does
> not return things properly for a case where the full data should be available.
> 
> - I think the check in getStackDepth should be maxDepth != 1 instead of
> maxDepth > 1.  A max depth of 0 will trigger a -stack-info-depth without any
> params, which request the full depth.  This will happen if you turn off the
> "Limit number of stack frame preference".  Pref->Run/Debug->View performance.

Good catch. Will adjust

> - from comments I got from the gdb experts for tracepoints, when the call
> [snip]
> I wanted you to know all the details.

I think trying "one more time" is enough of a hack. Trying numerous times is too much of a hack, IMO.

> - if you fix getStackDepth, do you still need to modify getFrameData()?  If
> getDepth() returns a proper depth, I think getFrameData will only ask for
> frames in that depth range.  

That's what I figured, but we end up still asking beyond what we get from the stack depth command. Not sure why, but I didn't have time to go down that tangent.

> If you do, then I think the change you made only
> makes sense in the case where miFrameDmc.fLevel == 0.  Also, you can probably
> call the method getTopFrame()

OK. I added the check for the level.
Comment 8 John Cortell CLA 2010-05-03 14:26:35 EDT 
Created attachment 166827 [details]
Updated patch based on Marc's review

Committed to HEAD.
Comment 9 John Cortell CLA 2010-05-03 14:26:49 EDT 
Fixed
Comment 10 CDT Genie CLA 2010-07-28 15:25:20 EDT 
*** cdt cvs genie on behalf of jcortell ***
Bug 311380: Interrupting target can leave Debug view in awkward state

[*] MIStack.java 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIStack.java?root=Tools_Project&r1=1.12&r2=1.13