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.
NB 6.7 RC3 Hi from time to time the F5 "Continue" button is disabled when a brekpoint is hit. Also the "Debugging Window" is not showing the current suspended thread. Call stack window is showing the suspended thread's stack. I must press on pause, then on continue to free the thread (Pressing pause causes the continue button to become enabled). Also after hitting the F8(step over) the continue button is still disabled.
Created attachment 84111 [details] Breakpoint hit screenshot
I thought that this was fixed by issue #160747. But apparently not, if it still occurs. Can you please describe some more concrete steps how can we reproduce this? And what kind of application do you debug - is it a standard J2SE app or servlet or J2EE app? Thanks.
Thanks for the screenshot, I guess it's a J2SE app where a breakpoint is hit in various threads. Possibly, one breakpoint can be hit by multiple threads at the same point. Maybe this is causing the bug.
My application is J2SE and all projects are maven based. But on the mailing list is another user that say it happens on a web project: [nbusers] Problems debugging servlet in 6.7 RC3 From: "Mark Claassen" To: nbusers@netbeans.org I am debugging a servlet and everything seems to work fine. However, occasionally after I stop at a break point the "continue" button will be disabled. I can still step-in / step-out, but that is not too helpful when I want to continue. Once I get in this state, I basically have to stop debugging and start over. Has anyone else noticed this issue? Mark
I can also confirm this problem on 6.7RC2, 6.7RC3 and 6.7 release. For me it happens on Single Threaded Java SE client app.
*** Issue 168293 has been marked as a duplicate of this issue. ***
*** Issue 168815 has been marked as a duplicate of this issue. ***
Hopefully fixed after improvements in processing of events and suspends/resumes of threads. changeset: 138898:a36822ba306f http://hg.netbeans.org/main/rev/a36822ba306f changeset: 138903:542432c0bb74 http://hg.netbeans.org/main/rev/542432c0bb74
Integrated into 'main-golden', will be available in build *200907240201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a36822ba306f User: mentlicher@netbeans.org Log: #167776 - Changes in threads management that should together with previous change resolve inconsistencies with parallel processing of events and suspends/resumes.
The bug persists in the latest build... At least in Ubuntu 8.04. Here is my 'about' message: Product Version: NetBeans IDE Dev (Build 200907310201) Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b16 System: Linux version 2.6.24-24-generic running on i386; UTF-8; pt_PT (nb) Userdir: /home/carlos/.netbeans/dev
carloscorreia, can you please provide some steps how did you reproduced this in the latest dev build? If this still occurs there must be some use-cases which I did not perform, continue button works quite reliably for me now.
*** Issue 160747 has been marked as a duplicate of this issue. ***
Also please note that there's issue #166579, which is likely jdk6u14-specific. Do you encounter problems with Continue even on older JDKs or with "-J-XX:+UseParallelGC" option added to NetBeans?
Nothing more that was previously said. I couldn't reproduce it on a small program, though. But if you pick a large project, define some breakpoints, and try to debug it, after hiting 2 or 3 breakpoints, you'll notice that the button isn't enable anymore. I tried also with Ubuntu 9.04, same problem. If there is a way to provide more info (a log file, perhaps), I'll be glad to help.
Thanks. I do not think we can find the cause from the log file, unfortunately. But if you can test it with "-J-XX:+UseParallelGC" option in etc/netbeans.conf, it would at least provide an indication if it's specific to JDK 6 update 14 (where regression http://bugs.sun.com/view_bug.do?bug_id=6862295 was found) or not.
I've test it with "-J-XX:+UseParallelGC" option in etc/netbeans.conf, but both the 'Continue' button as 'F5' key remain disabled.
@mentlicher: It seems to be a JDK bug after all. Sun's Java 6 packages in Ubuntu Hardy have been updated about a month ago. I then downgraded to a previous version and, now, debuging is working fine :) Note to Ubuntu (and problably, Debian) users: version 6-14-0ubuntu1.8.04 of sun-java6 should be downgraded to a previous one.
*** Issue 169705 has been marked as a duplicate of this issue. ***
I'm able to rarely reproduce this by attaching debugger to another NetBeans instance and adding line breakpoint to org.openide.nodes.Node.java:1224 (module openide.nodes). In the debugging NetBeans I press Continue very fast (or hold down F5) and the NetBeans which I'm attached to are starting up or opening/closing/expanding projects. From time to time I get Continue disabled (on JDK 6 update 15).
It looks that I really hit http://bugs.sun.com/view_bug.do?bug_id=6862295 here. The mechanism how it happens that Continue is disabled is, that we get a breakpoint event on a thread for which we did not receive ThreadStartEvent. Therefore we do not have such thread in the cached listing of threads and therefore it's not visible in Debugging window and we do not know that it's suspended. Since we suppose that all threads are running (we do not see the suspended thread), Continue remains disabled. The JDK bug should be resolved soon, but it looks like we can also implement a workaround in NetBeans.
I've found that there are two issues in fact. One is caused by JDK bug, as described above and will be fixed in issue #166579. The second issue is caused by a race-condition in NetBeans debugger. It occurs quite rarely for me, but following log illustrates the problem: FINE [org.netbeans.modules.debugger.jpda.jdievents]: HAVE EVENT(s) in the Queue: event set, policy:1, count:1 = {BreakpointEvent@org.openide.nodes.Node:1224 in thread Default RequestProcessor} FINER [org.netbeans.modules.debugger.jpda.jdievents]: Suspend count of instance of org.openide.util.RequestProcessor$Processor(name='Default RequestProcessor', id=8188) is 1. FINER [org.netbeans.modules.debugger.jpda.jdievents]: Write access lock TAKEN org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl$ThreadReentrantReadWriteLock$ThreadWriteLock@132b165[Locked by thread Debugger operator thread] on thread instance of org.openide.util.RequestProcessor$Processor(name='Default RequestProcessor', id=8188) FINE [org.netbeans.modules.debugger.jpda.jdievents]: event thread Default RequestProcessor is suspended = true FINE [org.netbeans.modules.debugger.jpda.jdievents]: JDI new events (suspend one)============================================= FINE [org.netbeans.modules.debugger.jpda.jdievents]: event is silent = false FINE [org.netbeans.modules.debugger.jpda.jdievents]: JDI EVENT: BreakpointEvent instance of org.openide.util.RequestProcessor$Processor(name='Default RequestProcessor', id=8188) : org.openide.nodes.Node:1224 FINE [org.netbeans.modules.debugger.jpda]: VM resume FINE [org.netbeans.modules.debugger.jpda.jdievents]: event thread Default RequestProcessor suspend before exec = true FINE [org.netbeans.modules.debugger.jpda.breakpoints]: BreakpointImpl: perform breakpoint: org.netbeans.modules.debugger.jpda.breakpoints.LineBreakpointImpl@ce8cfb resume: false FINE [org.netbeans.modules.debugger.jpda.jdievents]: JDI events dispatched (resume false) FINE [org.netbeans.modules.debugger.jpda.jdievents]: resume = false, startEventOnly = false FINER [org.netbeans.modules.debugger.jpda.jdievents]: Write access lock RELEASED:org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl$ThreadReentrantReadWriteLock$ThreadWriteLock@132b165[Locked by thread Debugger operator thread] FINER [org.netbeans.modules.debugger.jpda]: Debugger WRITE lock taken. FINE [org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl]: Resuming thread Load Open Projects FINE [org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl]: Resuming thread Default RequestProcessor FINER [org.netbeans.modules.debugger.jpda]: Debugger WRITE lock released. We receive breakpoint event, but Continue resumes the thread later and leave debugger in an inconsistent state.
It's hopefully finally fixed by synchronous set of debugger state in changeset: 140592:98fac5c18fca http://hg.netbeans.org/main/rev/98fac5c18fca I was able to perform tens of thousands Continue invocations without Continue button being disabled. I've tested that in both single-threaded and multi-threaded applications. Please verify that it works fine after this fix propagates to 6.8 dev builds.
Integrated into 'main-golden', will be available in build *200908080201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/98fac5c18fca User: mentlicher@netbeans.org Log: #167776 - Assure that the debugger state is set synchronously under a lock.
What will it take to make the fix available as an update to NB 6.7?
An update for NB 6.7 would be highly appreciated by our team.
verified in NB 6.9 RC1
Reproducable in netbeans 8.0.2 Product Version = NetBeans IDE 8.0.2 (Build 201411181905) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.8.0_51 Runtime = Java HotSpot(TM) 64-Bit Server VM 25.51-b03 Either hitting the toolbar button 'Continue' by mouse click or by keyboard key stroke too fast, disables the button and halts execution at the breakpoint where I started from. It is not reproducible with any breakpoint, it looks as if some special conditions have to be met. It is possible to get out of that situation by pressing 'Pause'; after that 'Continue' works again. It is possible to avoid the situation by waiting until the Variables View or the Watches View have been updated completely. Sometimes something similar happens when single-stepping (Step Over) through the code. In that case I can not manage to get out of the stuck situation. Hitting 'Pause' leads to nearly all buttons being disabled and the debugger hangs. Only 'Finish Debugger Session' and 'Apply Code Changes' stay enabled. 'Apply Code Changes' starts to reload the affected class, but becomes stuck. 'Variables View' shows some 'Evaluating...' messages, 'Breakpoint View' and 'Call Stack View' show 'Please wait...' but this last forever. (No need to say that 'Finish Debugger Session' works as expected. ;-))
Apparently, quite hard to reproduce. I may have seen this already, but now I'm not able to reproduce. If you could provide some hints about how to increase the chance to hit this bug, it would be very helpful.
samkar, I've created a new issue for this: issue #254655. The current problem can be either an insufficient fix of this issue, or a newly introduced bug, but anyway it occurs much more rarely and it's more like P3 priority. Any information that can help with the reproducibility of this issue is welcome. Please provide it into issue #254655. I'm closing this issue as originally fixed in version 6.x.