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.
This problem appeared approximately a week ago, and it is a serious regression, that's why I set high priority P1. Start Debugging is broken - it does not really start the debugging, it stops after loading the program and setting breakpoints. Here is a test case: 1. Create a project Qoute, and set a breakpoint on line 50 in file quote.cc You don't need to start debugging, just set this breakpoint 2. Create a project HelloApp, and start debugging (press "Debug Main Project") Debugger windows appear, program I/O window appear, there are many messages in Debugger Console, but debugging process does not start. Status in Debugger Console says: loaded. Here is a log file from Debugger Console: ========================================= Start debugger gdb gdb_cmd=gdb --nw --interpreter=mi --tty /dev/pts/18 ~"GNU gdb 6.4\n" ~"Copyright 2005 Free Software Foundation, Inc.\n" ~"GDB is free software, covered by the GNU General Public License, and you are\n" ~"welcome to change it and/or distribute copies of it under certain conditions.\n" ~"Type \"show copying\" to see the conditions.\n" ~"There is absolutely no warranty for GDB. Type \"show warranty\" for details.\n" ~"This GDB was configured as \"i386-pc-solaris2.10\"." ~"\n" (gdb) 212-file-exec-and-symbols /tmp/nikm/SunStudioProjects/HelloApp1/helloapp/dist/Debug/helloapp 212^done (gdb) 221-break-insert /home/nikm/SunStudioProjects/Quote1/quote.cc:50 &"No source file named /home/nikm/SunStudioProjects/Quote1/quote.cc.\n" 221^done (gdb)
I think it is related to these changes in GdbDebuggerImpl.java, that were done 2006/09/06 10:44:24 (sorry, I said a week ago, actually only 2 days ago): if (reply == null) { - setRunning(); // Must be before exec_run because it triggers breakpoint setting - reply = gdb.exec_run(pae.getProfile().getArgsFlat()); + setLoading(); } We have discussed these changes with Gordon, and I think we have a fix for this bug. A workaround is to manually execute GDB/MI command "exec-run" in Debugger Console window.
For preliminary tests it works. I'll keep trying other projects, etc. I've only tried it on Windows, so far. I can also try it on Linux. I'll have to wait until next week to try it on Solaris.
I can reproduce this problem on Solaris, Linux, and Windows. There is no platform specific. The test case that I provided should be enough to reproduce it anywhere. It happens every time I start debugging *ANY* project. Honestly, I thought to add "-exec-run" to the list of Debugger Console commands, because it is annoying to type it every time :-)
I now understand the problem and should have a fix this afternoon. Whats happening is that during debugger startup each breakpoint is sent to gdb for validation. Since the answer is received semi-asynchronously, each breakpoint is stored in a validation-pending list. Each time a bp is validated its removed from that list and checks if the list is empty. If the list is empty, it sets the state to Running and execution starts. Whats causing the problem is that sometimes breakpoints fail validation. This happens because the debuggercore sends all breakpoints (for the current debugger's languages) to the debugger. In this case, gdb validates the bp from one project (the one being debugged), but sends back an error for the bp in the other project. However, since the validation doesn't change state until all bps are validated, the failed validation keeps the list from going to 0 so the state is not changed to Running. The solution is to track failed validations and remove them from the validation-pending list (this should be very easy to do because we just have to parse the message in ^error lines received from gdb). When the validation fails, if the bp is removed from the validation-pending list then the list becomes (eventually) empty and state is set to Running.
As a workaround (until I commit a fix): Remove all breakpoints in projects other than the one being debugged (in this case, the one from quote).
Breakpoint validation stores an unvalidated breakpoint request in a pending list while waiting for gdb to validate the breakpoint. If its sucessfully validated, its removed from this pending list. The problem was that failed validation left the request in the pending list and we never went from state LOADING to state RUNNING until the pending list was empty. The fix is to track failed validation. Since the netbeans debuggercore insists on sending all C and C++ breakpoints to gdb (even if from another project), its easy to have failed breakpoints. Now they're correctly handled, though, and state gets changed to RUNNING (which triggers the -exec-running command to gdb). A side affect of this fix changed the way "tokens" are sent on some gdb/mi commands. A token is a numeric before the actual command. We used the same token for all -break-insert commands and sometimes had difficulty matching a response to the request (the logic to match was somewhat involved). The new scheme is to sent a unique token for each -break-insert request. That way we can always (quickly and cheaply) match the response to the request. The breakpoint tokens start at 500 so other gdb commands can still have their fixed tokens. The only requirement is that they all be below 500 so there is no chance of mistaking them for a -break-insert token.
verified in build 200711020000