Bug 167776

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.