This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I get the exception below when trying to start the debugger on Mac:. Note no remote setup and working locally. java.lang.StringIndexOutOfBoundsException: String index out of range: -203 at java.lang.String.substring(String.java:1768) at org.netbeans.modules.cnd.debugger.gdb.utils.GdbUtils.createMapFromString(GdbUtils.java:291) at org.netbeans.modules.cnd.debugger.gdb.GdbDebugger.resultRecord(GdbDebugger.java:849) at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.processMessage(GdbProxyEngine.java:321) at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.access$000(GdbProxyEngine.java:76) at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$2.run(GdbProxyEngine.java:207) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)
It looks like its processing data returned from stopping at a breakpoint. To really verify this we need to use the same test program with the same breakpoint. Do you remember what program and what line of code your breakpoint was set at? Was it a C or C++ program? When gdb stops it sends various pieces of data back. This exception happened while parsing that data. Thats why knowing the program and line of the bp are so important. We could be failing on a specific set of data received from gdb, but stopping in other programs or at other lines may not send data we can't parse.
It chokes when parsing the following string: "number="1",type="breakpoint",disp="del",enabled="y",addr="0x00001f97",func="main",file="src/args.c",line="50",shlib="/Users/thp/NetBeansProjects/Arg uments_1/dist/Debug/GNU- MacOSX/args",times="0"},time={wallclock="0.00062",user="0.00039",system="0.00023",start="1217563641.232985",end="1217563641.233601"" when it gets to shlib.... It happens with *any* program I'm trying to debug.
please attach full gdb-log
and where do I find it?
usually at /var/tmp/gdb-cmds####.log or /tmp/gdb-cmds####.log
> and where do I find it? I seem to remember it being harder to find on a Mac. If you can't find it, copy ~gordonp/NetBeansProjects/SystemProperties/dist/SystemProperties.jar, run it, and check the value of java.io.tmpdir. The jar file dumps the output of System.getProperties()...
Created attachment 66327 [details] log file
The problem is that for some reason "timings" is enabled on your version of gdb, because of that gdb adds time=... epilog to every response and we do not expect that. Proposed fix is to send -enable-timings no to the debugger at the beginning, I implemented it in the changeset: http://hg.netbeans.org/main/rev/05acbd98cefc
Wouldn't it be better to just parse the string correctly?
I think that if we do not use this information, why shouldn't we disable it? It can double gdb transport traffic.
While I agree we shouldn't turn on timing, we should also parse the line correctly if it is on. This problem shows that there is at least 1 case where GdbUtils.findMatchingCurly() fails. If there's on, how do we know there aren't others? I do think your fix resolves the P1, though. I suggest closing this as fixed and opening a P2 on findMatchingCurly() (or possibly a P3 since we've only seen this one case of it failing).
No, it didn't fix th problem. It fails same plase as before. New log attached.
Created attachment 66338 [details] log file
I noticed debugging fails only if I do 'Step Into' but seems to work if I do Debug. I don't know if it helps.....
I borrowed Thomas' Mac so I could debug in his enviornment. First off, it looks like Apple broke gdb/mi wrt -enable-timer because even though you explicitly turn it off, its still on. Thomas said he downloaded a new X-Code recently and probably got an updated gdb with this problem. But the actual cause of the problem isn't in GdbUtils, its in GdbDebugger.resulteRecord where it processes "^done,bkpt=". There is an assumption that the entire msg is the breakpoint data so we strip off the 1st and last characters ('{' and '}') before passing the string to GdbUtils.createMapFromString(). Since this assumption is incorrect, we end up with "},time={" in the middle of the string passed to cMFS. In his 2nd log, the same thing is happening in "^done,stack={...},time={...}". Again, we assume one outer set of curly braces, strip them off, and assume everything left is part of the stack. There are several other places where we make this same assumption. We should probably find the closing curly and send a substring rather than make this assumption (although its really an Apple gdb bug causing the problem). We probably don't need to explicitly send the -enable-timer off flag (since it doesn't work, anyway:-)
-enable-timings does not work because gdb does not recognize this command: 104^error,msg="Undefined MI command: enable-timings"
Now we check every debugger response for timing info and cut it out, implemented in the changeset: http://hg.netbeans.org/main/rev/8f3fc2197825
Fix confirmed: Debugging now works again on my Mac.
*** Issue 146691 has been marked as a duplicate of this issue. ***
Verified in trunk by Thomas. The fix should be included into patch 4.
Will the fix be incorporated into the 6.1 tree at all? Some of us have no immediate plans to upgrade to 6.5 until it has been stable for a while.
> Will the fix be incorporated into the 6.1 tree at all? Yes. The fix is scheduled for patch 4 (the next patch).
I've transplanted those changesets into release61_fixes repository. http://hg.netbeans.org/main/rev/05acbd98cefc to http://hg.netbeans.org/release61_fixes/rev/0ac9edbb223e http://hg.netbeans.org/main/rev/8f3fc2197825 to http://hg.netbeans.org/release61_fixes/rev/1d3a324e3852
verified in patch4