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.
The debugger has always been unusable for me with JDK 1.4. I hoped it would change with NB 3.4 but it's not the case. Sometimes "step over" does not jump to the next line. There is a message saying "Thread ... stopped at ... line ..." but the line is not highlighted in green. Sorry I couldn't find a reproductible test case but it happens frequently enough to prevent me to work with NB and JDK 1.4 :-( I tried to rebuild all with 1.4 compiler, but without success. The problem is described by some users in the nbusers thread named "Debugger on 3.4 steps over huge blocks..."
Created attachment 7313 [details] ide.log
See also #13278 for a similar problem. I reinstalled JDK 1.3.1 but the problem is not gone :-(( even if it happens less frequently. Sometimes pressing F8 does not go to next line. Then after Debug/Pause and a few seconds, the program stops again at the same line, but never goes further. I think I'll reinstall NB 3.3.2 or perhaps Eclipse (sorry but I need to get my work done).
Very annoying. Frequently doesn't go anywhere after trying to continue or step-over after a breakpoint. If I pause then the green arrow is redisplayed at the line where I tried to continue from. I have jdk1.3.1
Very similar behaviour here. The debugger output shows the step, but no annotation (green arrow) is there. In the debugger window the state says "Running". If I pause then sometimes the green arrow appears. Sometimes it stays on the same code line and I need several iterations of Step over / Pause until it stops correctly.
I find the same thing with q-build 200212180100. JDK 1.4.1, Win98. It appears that not only the annotation is gone but also the debugger refuses to execute step requests. Clicking on the last link in the debugger console fixes it. However I am not 100% sure because I have a very slow computer. Another observation is that the debugger annotation sometimes jumps up the call hierarchy for no reason although the current method is still executing and has more statements. Again, clicking on the last link in the debugger console fixes this. There is a related issue 29560 that has a reproducible testcase.
I will look at it.
*** Issue 31926 has been marked as a duplicate of this issue. ***
too late
Hopefully this is not too late for NetBeans. Sorry for this comment. Of course I am very interested in the success of NetBeans, and that it gets as many happy users as possible. However with a bug like this persisting for so long I wonder who is actually using NetBeans, and I wonder whether new users will use it. Nevertheless, good luck and all the best.
I must also say I'm very sad about this bug not fixed and not marked as high priority because it's a major function not working, I can't see the use of an IDE if debugging does not work. I know it's open source and I shouldn't complain and fix this myself, but I had a lot of hope in this project since the beginning (I bought a licence) and I feel disappointed. Please stop adding more new features and fix more old bugs. Thanks.
I would like to fix this bug, but I do not have testcase, and I can not reproduce it regulary. Issue 29560 is fixed, so the only one reproducible testcase is in 27013, but I do not think that its exactly your problem. Can you help me and find some regular set of steps to reproduce it frequently? Does this problem depend on JDK version? Thank for your help.
I'll try again to make a testcase even if it's difficult. But I have a clue that could help: if I set the debugger's classic switch to true it seems to work much better (although other bug reports recommend to set it to false...)
This exception appeared during my debugging tests. I don't know if it's related to our problem, but here it is: Annotation: Exception occurred in Request Processor java.lang.ArrayIndexOutOfBoundsException: 0 at org.netbeans.modules.debugger.support.java.nodes.JavaVariablesRootNode$VariablesRootChildren.validate(JavaVariablesRootNode.java:170) at org.netbeans.modules.debugger.support.java.nodes.JavaVariablesRootNode$VRListener.propertyChange(JavaVariablesRootNode.java:291) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:252) at org.netbeans.modules.debugger.support.java.JavaThread.firePropertyChange(JavaThread.java:377) at org.netbeans.modules.debugger.jpda.JPDAThread.refreshStack(JPDAThread.java:567) at org.netbeans.modules.debugger.jpda.ThreadManager.refreshStacks(ThreadManager.java:193) at org.netbeans.modules.debugger.jpda.JPDADebugger.updateUINow(JPDADebugger.java:716) at org.netbeans.modules.debugger.support.java.JavaDebugger$1.run(JavaDebugger.java:469) at org.openide.util.Task.run(Task.java:136) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599)
It indicates bug in JPDA debugger like in 27013. This is hard to fix :( Can you attach some piece of code?
I have not been able to reliably reproduce this although it happens very often. The conditions are not clear to me, in fact it appears to occur randomly. Very confusing and inconclusive. Processor speed doesn't appear to be an issue; I have seen this with 200MHz and 2GHz processors. I would definitely recommend to try it exclusively with JDK 1.4 and SDI mode unless someone else reports different settings. It's reported on Win2000 and I get it on Win98. So it might be best to hunt this on one of these platforms. I am usually quite persistent in making testcases eventually but with this issue I don't have any idea yet. As far as I can see, there are apparently 3 different symptoms which might boil down to at least 2 different bugs: 1) The anotation is lost and stepping continues which can only be verified by viewing the debugger console. 2) The focus jumps up the call hierarchy, often in a different class. The annotation is visible. Rescue is possible with clicking on the last link in the console. 3) The session gets suspended with a beep and the annotation is also lost. In that case, the session can only be rescued by resuming it. Burning question: Is there a way to write a patch that I can apply that logs additional information that could be helpful to reveal the bug?
Some more info. The bug also appears with classic switch to true :-( Apparently it is only the action of changing the switch (to false or to true) that makes the bug disappear temporarily. But now the only fact to double click on a breakpoint, to remove it and to set it again, makes the bug reappear. Very strange... I'll try to send some code, but apparently it won't be enough, there is also some scenario which is hard to reproduce.
Created attachment 9700 [details] Thread dump (Ctrl-Break) when debugger is blocked
Perhaps this bug is related with bug 22795, which is marked as fixed but in fact is _not_ fixed in the latest release (3.4.1)
It should be fixed in nb3.5 can you try our latest build?
OK I'll try this when 3.5 is out (I prefer not to use dev build for production work). Thanks!
Created attachment 9725 [details] Testcase main class
Created attachment 9726 [details] Testcase other class (required)
This testcase for me reproduces always all of the 3 scenarios that I listed above on 2003-04-04. Let me suggest to lift the priority of this. Good luck!
I've just tested with NB 3.5 beta and Bernard's testcase, but the bug is still there :-( Note that the bug appears only if local variables are displayed in the debug window. The priority of this bug should also be changed, this is a major defect. Thanks.
I am sure there are other issues with the debugger that are hard to distinguish from this issue. I am sometimes finding myself in a situation where all the kick-starting that are described here as workarounds do not help anymore. In some cases, I can pause and resume to get a few steps of execution and then the debugger disappears again, nowhere to be traced. So I pause and resume and I get a few executions again. Then there may be some code that takes a long time to execute. How can I tell the difference? You see what I mean? The debugger is useless if it is not dependable.
I have the problem like Bernard has. "Step nowhere" syndrome takes place during, I think, at least 1-1.5 years. It is very annoying when you are debugging WEB-application. The cycle is: stop Catalina, edit, deploy, start Catalina, _do all needed steps_ in WEB-scenario, then - take the issue. I'm sure, the issue has P1. I see, nothing information is deleted. But some months ago one of NB development gurus have said me in mailing list, that when some bug is _very_ annoying, it _can_ has P1. Env: all this period I work with builds from current CVS dev. trunk, win 2000 or win XP, last j2se.
Thank you Bernard for yor testcase. I can reproduce it now, and I will look at it.
I can reproduce the problem(s) quite reliably on Win XP + JDK 1.4.1_01 (MDI) using the test case provided by Bernard T, too. Hanz, could you prepare a patch to log relevant info on the internal debugger state during stepping? I'll be happy to test with it for you.
I tried to hide the 'Watches' and 'Local Variables' panes and left only the 'Call Stack' pane on. I wasn't able to reproduce the problem after that. Bringing up the 'Local Variables' pane back caused the problem to reoccur in 4 or 5 steps. When it occurs, selecting Debug | Pause followed by Debug | Continue seems to bring the debugger back to a functional state.
... not quite reliably though. :-(
What I exactly see is: 1) quickly pressing F8 + Variables view is opened => sometimes "unpause" debugging (debugger is running, but current line is set) => sometimes stops debugging inside the StringBuffer class + debugger state is inconsistent - ui state is "running" but internall state is stopped 2) quickly pressing F7 + "fid source option: => sometimes "unpause" debugging (debugger is running, but current line is set) >> 1) there is some timing problem 2) looks like more than one bug is there
Hi, my OS is Solaris. Although I am not able to reproduce this problem by hand (I happened to me during common debugging, but I was not able to reproduce it on purpose), I have written a class, that calls StepOverAction as fast as possible. This is repeated 5000 times. It seems to me that I am able to reproduce some problems now (after a few hundreds or thousands of step overs): 1. Sometimes, the debugger just looses the PC annotation, but after next step over it goes right 2. Sometimes, the debugger switches into "Running" state, although there is no reason (it should only do step over and stop). Presing Debugger/Pause recovered debugger in 100% of tested cases. (Please note that problem 1 does not block execution of the attached "Stepper" class, so you have to watch carefully if you want see it. Problem 2 blocks execution of the "Stepper" class.) The test case is by Bernard T from 6 April 2003. Steps to reproduce: 1. Download attached "Stepper" class. 2. Setup the environment as if you would like to test Bernard's test case by hand (incl. starting debugger over it). 3. Compile&rung "Stepper" class (requires openide.jar and debuggerCore.jar, and should be runned using internal execution). 4. Wait until something wrong happens (may take quite a long time). This means that this problem occurs also on Solaris, only it is much less probable than on Windows.
Created attachment 10232 [details] "Stepper" class.
*** Issue 33486 has been marked as a duplicate of this issue. ***
Problem Description: ==================== Occasionally when a user is very quickly stepping through a code (Step Into - F7, Step Over - F8), debugger state becomes unconsistent. The problem has several faces: Stepping (F7 or F8) thouogh the code. 1) F8 has been pressed & process is stopped & debugger state is paused & debugger console and status line contains correct message (stopped on line xx) & step actions are enabled & editor is on the right place BUT: current line is not set 2) F8 has been pressed & process is stopped & current line is set & debugger state is paused & debugger console and status line contains correct message (stopped on line xx) & editor is on the right place BUT: step actions are disabled 3) F8 has been pressed & process is stopped & debugger state is paused & debugger console and status line contains correct message (stopped on line xx) & step actions are disabled BUT: editor is not on the right place, but one level up in the call stack of the current thread 4) various combinations of 1-3 can occure too. 5) F8 has been pressed & process is running & debugger state is running & step actions are disabled & current line is set on previous line 6) F7 has been pressed & process is running & debugger state is running & step actions are disabled & current line is not set Evaluation: =========== add 1) this problem occures in the following scenario: i) F8 is pressed ii) step request is created and registerred iii) debugger state is set to running iv) step actions are disabled v) Virtual Machide is resumed vi) step event is notified by jdi & process is paused vii) debugger state is set to paused viii) step actions are enabled ix) correct message is written to status line & debugger console BUT: current thread returns bad values from getSourceName (), getClassName () and getLineNumber () methods in JavaThread.setCurrent () method Further investigation is needed - why the values are incorrect. Possibilities: - Bad values are returned from jdi interface. But we have tested this jdi functionality externally (outside NetBeans) and the problem has not been reproduced. - Some bad synchronization in our implementation of this methods Fix of this problem may require some archirecture changes of jpdaDebugger module add 2) this problem occures in the following scenario: i) F8 is pressed ii) step request is created and registerred iii) debugger state is set to running iv) step actions are disabled v) Virtual Machide is resumed vi) step event is notified by jdi & process is paused vii) debugger state is set to paused viii) current line is set ix) correct message is written to status line & debugger console BUT: during the debugger state evaluation JPDAThread.isSuspended () method returns false (in JavaDebugger.updateStoppedState () method) Further investigation is needed - why the suspended state is incorrect. Possibilities: - Bad values are returned from jdi interface. But we have tested this jdi functionality externally (outside NetBeans) and the problem has not been reproduced. - Some bad synchronization in our implementation of this methods Fix of this problem may require some archirecture changes of jpdaDebugger module add 3) the same problem as 1), but getLineNumber () method call in JavaThread:130 returns incorrect value too. add 5) this problem occures in the following scenario: i) F8 is pressed ii) step request is created and registerred iii) debugger state is set to running iv) step actions are disabled v) Virtual Machide is resumed AND: step event is not notified by jdi & process is not paused Further investigation is needed - why the step event is not notified. Possibilities: - Some bug in jdi implementation. But we have tested this jdi functionality externally (outside NetBeans) and the problem has not been reproduced. - Some unpredicable problem in our implementation, but I have no idea now how it can happen. add 6) this problem looks similair to 5) but its not evaluated yet,
case 1) and 3) leads to following exception: com.sun.jdi.IncompatibleThreadStateException at com.sun.tools.jdi.ThreadReferenceImpl.frameCount(ThreadReferenceImpl.java:263) at org.netbeans.modules.debugger.jpda.JPDAThread.getLineNumber(JPDAThread.java:101) at org.netbeans.modules.debugger.support.java.JavaThread.setCurrent(JavaThread.java:149) at org.netbeans.modules.debugger.jpda.JPDADebugger.makeCurrent(JPDADebugger.java:733) at org.netbeans.modules.debugger.jpda.StepManager.exec(StepManager.java:453) at org.netbeans.modules.debugger.jpda.util.Operator$1.run(Operator.java:104) at java.lang.Thread.run(Thread.java:536) exception is hidden (catched) by jpdaDebugger in the situation, in which it should not occure.
looks like 1 - 3 are caused by something similair to 4257690.
status update for cases 1 - 3: - I know how to fix it - but fix is not trivial. Looks like some middle size redesign of jpdaDebugger implementation. - I PROBABLY know the root of the problem, but I am still not sure if its bug on our side of JDK one. I have not found the corresponding bug in JDK database, and I do not have testcase how to reproduce it outside the IDE. - 5) & 6) looks like different problem
NetBeans 3.5 rc2; jdk1.3.1_02 I changed a source file OtherClass.java a little bit. I removed the StringBuffer object from source code therefore the line 12 looks 'String dirBuf = new String(_string1);' and the line 13 looks 'dirBuf.concat("dgfdgfg");'. I placed a line breakpoint at line 10 and started debugger - similar test case like it was previously written. When the breakpoint was hit I invoked an action 'Step Over' (F8) several time. IDE hung after while - the thread dump is attached. It is a quite well reproducible.
Created attachment 10342 [details] thread dump
Using RC5 I can't reproduce this with JApllet. I create JApplet with Start button (similar to example of Bernard T) and debugger works correctly with this. I'll attach my example. (I'll attach only applet class. Please, use OtherClass already attached.) Some problems exist in JSP debugging. I'll attach example. You also need to use OtherClass already attached. reproducing steps you may find inside Jsp file. I don't think that this bug is P1. Just because it's workaround exist. You need to pause debugger and continue it by one of debugger action.
Created attachment 10398 [details] Connot reproduce with this testcase.
Created attachment 10399 [details] JSP example (repr. steps inside)
To Vladimir: unfortunately, the Pause/Continue workaround does not work reliably in all cases. Sometimes it helps, but other times, the user has to finish the debugging session and start a new one. Another "workaround" is to step slowly and wait until the UI settles before the next step, but I'm hesitant to recommend it to the users.
Workarroung does not exists for 5 & 6 (when debugged process is resumed during stepping). For 1-4 I use following workarround: 1) open threads view 2) select some thread which is not current & doubleclick on it 3) select thread which was originally current and doubleclick
I have created a log extension as part of issue 33882, but I am not able to simulate the behaviour - somebody else has to.
Created attachment 10429 [details] ide.log with aspectj logging (case 5)
The previous attachment includes logs of communication via JDI recorded when case #5 occured at line 16 of the OtherClass testcase (Debugger running, current line = 16, debugger actions disabled, debugged process resumed). Thanks Jarda for the logging feature. Someone else has to analyze the logs though. I'm going to attach more of them when I reproduce the other symptoms.
Created attachment 10430 [details] F7 until case #6 occured at OtherClass:12
Created attachment 10431 [details] F8 until case #2 occured at OtherClass:12
Comments to case2-ide.log: Pressed F8 for a while, got case #5, but continued debugging and stepping until case #2 occured at OtherClass:15 (thread stopped, correct message in status bar, debugged process stopped, but debugger actions disabled).
Created attachment 10432 [details] F7 until case #4 occured at OtherClass:12
Comments to case4-ide.log: Stepped via F7, got case #6, but continued debugging and stepping (into) until a combination of symptoms occured (debugger running, process stopped, debugger actions disabled, current line not set (grayed)). Please pay attention to suspicious exceptions at the ends of the last two logs.
I noticed a pattern common to all but the very first (case #5) log. See the following log fragment (edited): ... call(ThreadReference com.sun.jdi.event.ThreadStartEvent.thread()) call(ThreadGroupReference com.sun.jdi.ThreadReference.threadGroup()) call(boolean java.util.Iterator.hasNext()) call(void com.sun.jdi.VirtualMachine.resume()) --- Operator.run() call(EventSet com.sun.jdi.event.EventQueue.remove()) call(EventIterator com.sun.jdi.event.EventSet.eventIterator ()) call(boolean java.util.Iterator.hasNext()) call(Event com.sun.jdi.event.EventIterator.nextEvent()) call(EventRequest com.sun.jdi.event.Event.request()) call(EventRequest com.sun.jdi.event.Event.request()) call(Object com.sun.jdi.request.EventRequest.getProperty (Object)) --- ... repeated several times, until... --- call(ThreadReference com.sun.jdi.event.ThreadDeathEvent.thread()) call(ThreadGroupReference com.sun.jdi.ThreadReference.threadGroup()) call(boolean java.util.Iterator.hasNext()) call(void com.sun.jdi.VirtualMachine.resume()) --- Operator.run() call(EventSet com.sun.jdi.event.EventQueue.remove()) call(EventIterator com.sun.jdi.event.EventSet.eventIterator ()) call(boolean java.util.Iterator.hasNext()) call(Event com.sun.jdi.event.EventIterator.nextEvent()) call(EventRequest com.sun.jdi.event.Event.request()) call(EventRequest com.sun.jdi.event.Event.request()) call(Object com.sun.jdi.request.EventRequest.getProperty (Object)) Note that the section that starts with call(ThreadReference com.sun.jdi.event.ThreadStartEvent.thread()) is repeated several times in the log. Near the end of the log, a 'Death' variant of the same call occurs call(ThreadReference com.sun.jdi.event.ThreadDeathEvent.thread()) It could be about the same time, the debugger state becomes inconsistent. Could this be a cause/sign of the problem?
Thank you for logs. call(ThreadReference com.sun.jdi.event.ThreadDeathEvent.thread()) maybe OK,but I want to study your logs more deeply.
I guess you're right. I put some extra logging into ThreadManager.addThread() and ThreadManager.removeThread() and it shows the dead thread is 'main' (logical) and the event is delivered long before the stepping problem occurs. Of interest might be that the parent ThreadGroup for the removed 'main' thread cannot be found, so the thread is never removed from the Threads view and remain visible with state 'Unknown'. I guess this is a bug, although it's probably not related to this problem. The question is, however, why the aspectj logging is interrupted shortly after the 'ThreadDeath' pattern in many of the attached logs.
Created attachment 10433 [details] fix #3
Created attachment 10434 [details] fix #3
Created attachment 10435 [details] Yet another F7 log
I can not reproduce given problem with fix#3 on jdk141_02 on win. Evaluation of variables / watches / tooltips is commented out in fix#3.
Comments to the last attached log: Note line 636: before: call(EventSet com.sun.jdi.event.EventQueue.remove ()) thread: Thread[Debugger operator thread,1,system] It's the last time you hear from the Debugger operator thread. The call seems to never return, there's no 'after' counterpart. Also note the section between lines 727 and 763. The same piece of code (evaluation of local variables?) seems to be executed from two tangled threads (AWT and Debugger Request Processor). Is that ok?
>Note line 636: This is strange, but Ido not understand exactly, what does it mean. EventQueue.remove should be blocking method... >Also note the section between lines 727 and 763. This is probably problem. I will synchronize this calls.
FWIW, I'm not able to reproduce the problem with the 'fix #3' jars. Now what? We need the expressions evaluation working.
Created attachment 10436 [details] fix#4
Looks like we have finally candidate for fix of this bug! everything should work, as I know. The only diference I know about is that during evaluation of locals / watches some "?" appears in value column for a while. deadlock should be fixed, evaluation is little bit slower, I am waiting on #737860905 (mob.phone) on your opinion. Should I check this fix to some branch? H.
Wow! Looks like this fix could really work! I have been trying hard but couldn't reproduce any of the symptoms described in this issue. No interrupted sessions, no deadlocks. Stepping does feel slower, but it's ok. Better slower than wrong. The fix needs more much testing on more platforms though. Yes, we need to get this into release35. Please work with Trung to integrate it asap. Be ready to roll back when something goes wrong :-) ... and THANKS!
Created attachment 10438 [details] ide.log with jdi exceptions
The fix still seems to work, but I found some debugging related exceptions in ide.log (see the previous attachment). Don't know what caused them. I tried mixing Step Into (F7), Step Over (F8) and Run To Cursor (F4). I also played with resuming various threads in the Threads view.
It seems that all those exceptions are generated when the debugging session is finished. Probably harmless, but should be supressed.
fix has been integrated to release35 branch i will look at these exceptions
I tested jsp debugger with the r35 debugger patch on w2k and it worked ok for me. The stepping is really slow, but it works. Vladimir has the primary word for jsp debugger tests, though.
With respect to performance, you might wish to re-evaluate a comment in issue 29560: *** Start quote ------- Additional Comments From Petr Kuzel 2003-01-13 05:03 PST ------- Dusan please evaluate if this call-stack visualization is desired. Compare it with content of call stack tab in debugger window. I think that such visualization should be by default off. Reopen if you conclude with the same result. Also please evaluate how 500ms delay inpact users experience. *** End quote
Issue 33486 has been marked as a duplicate of this issue, but it is not resolved by the patch. It still persists and can be reproduced in jsp debugger (or in java debugger with attaching to tomcat server) even with the patch.
I've try new nevada build (Build030525_1) and have following result: Looks like that this fix is ok. But 1 problem still exist: If I several times use Step * action inside class OtherClass, than press Debug->Continue, then press Debug- >Pause, Step * actions didn't became enable. Of course, I can open threads view, click twice on some trhead and this actions will enabled, but I think that Contunue-Pause action should automatically switch to necessary thread. I'm I right? This behaviour reproduced with pure Java apps and with JSP debugger. Also, I still can reproduce 33486.
>Of course, I can open threads view, click twice on some >trhead and this actions will enabled, but I think that >Contunue-Pause action should automatically switch to >necessary thread. I'm I right? 1) this problem is not connected to the current bug, and its not a bug but "as designed" feature :). So, if you have some idea how to change this behaviour, file a RFE, please. 2) I do not know what does it mean "necessary thread". May be that we can switch to the thread which has been current in the last time. But this thread can be in some unpredicable state - in native method, it can be dead. That is why we do not allow stepping. Is not clear where the debugger stops, and what should be debugged in that state after the pause action.
fixed in release35 & trunk branches. thanks for your help!!!
Verified on request of QA Team. Thanks :)