Bugzilla – Full Text Bug Listing
| Summary: | [Mac] Run To Line throws exceptions, breaks debugging | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Marc-André Laperle <malaperle> | ||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc-André Laperle <malaperle> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | pawel.1.piech | ||||||
| Version: | 8.0 | ||||||||
| Target Milestone: | 8.0 | ||||||||
| Hardware: | Macintosh | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I tested on Linux and Windows and it worked so this is a Mac only issue. Will investigate. Created attachment 180466 [details]
Run To Line Mac patch
Apple gdb doesn't provide the frame information in the *stopped event. When the event is dispatched, 3 methods are used to determine whether or not "Run to Line" has stopped at the right place. 2 of them need the frame information, the third one compares the Bp numbers. "But this does not work if another breakpoint was also set on the same line because GDB may return that breakpoint as being hit." I think it's better than nothing to rely on this when the frame info is not available. Therefore, this patch handles the case where the frame is null. I didn't create a patch for MacOSGDBRunControl because I think it's a safe change for all gdbs. I also reported the problem to Apple.
Looks good, thanks. Before I commit, can you post the gdb traces that cause this problem, just so I can visualize it better. Sure, thanks for looking at the patch.
657,810 23*stopped,time={wallclock="0.00171",user="0.00044",system="0.00047",start="1289440657.80614\
7",end="1289440657.807857"},reason="breakpoint-hit",commands="no",times="1",bkptno="2",thread-id="1"\
,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000000100000d51",func="main",fil\
e="../src/testRunToLine.cpp",line="14",shlib="/Users/mark/Documents/dev/workspaces/eclipsedev3.7-\
cocoa-test/testRunToLine/Debug/testRunToLine",times="1"}
Now I notice that there is enough information in there to create a MIFrame. I could override a bunch of things to make it work but I'm a bit nervous about relying on this particular output format. I don't have a 10.4 to test anymore so I don't know if this is consistent between the versions. In a full solution, it would still return a null MIFrame if something goes wrong and the patch attached here would still be useful as a fallback. What do you think? I would be inclined to open a different bug to address the null MIFrame on Mac and fix it when there is more incentive to.
Hi Marc, should I work on parsing the output to create a MIFrame or is the current patch OK for now? (In reply to comment #5) > Hi Marc, should I work on parsing the output to create a MIFrame or is the > current patch OK for now? Ok for now. I should have committed before but forgot. But it is better that way since you can commit it yourself :-) Fixed in HEAD. Thanks Marc. *** cdt cvs genie on behalf of mlaperle *** Bug 327061 - [Mac] Run To Line throws exceptions, breaks debugging [*] GDBRunControl.java 1.18 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.java?root=Tools_Project&r1=1.17&r2=1.18 |
Created attachment 180295 [details] Run To Line log Using CDT 8.0 from CVS HEAD (as of today) on Mac OS X using Apple gdb-1472. Will test on more versions and OS soon. 1. Create a Hello world C++ project 2. Start debugging, breaking at main 3. Use "Run To Line". Exceptions are thrown, see attachment.