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.
Created attachment 144474 [details] source, log, screenshot I see new problem on netbeans-trunk-nightly-201401270001-javase-windows: on pressing F7 (Step Into) NetBeans sends JDWP.ThreadReference.Resume, gets JDWP.Event.Composite.SINGLE_STEP - but still acts as if VM did not stop: F5,F7,F8 buttons are disabled. On the following snippet I get hangup on third line every time: > int ss = 0; // breakpoint is here, press F7 > for (int ii = 0; ii < 33; ii++) { // stop here, press F7 > ss += ii; // stop here, press F7 - and get hangup > } I checked the same JavaME app with NetBeans7.4 and NetBeans8.0beta - it works Ok. The problem can be reproduced without mobility pack. My script: start JavaME SDK emulator on win32, install midlet, run it with debugging, open HelloWorld.java in NetBeans, install breakpoint, use "Debug > Attach Debugger > port: 51301", see breakpoint stop, F7, F7, F7. We have JDWP proxy between VM and NetBeans. I will attach proxy log: nb_8_kdp.log that works Ok, and nb_dev_kdp.log that stops unexpectedly, shortened more user-readable version nb_dev_kdp_short.log, and NetBeans screenshot at the last moment.
This example works fine for me with Java SE. The step event is apparently received, the IDE asks for the thread name, etc. It shows the correct stack frames in Debugging view. But it blocks somewhere. Can you please provide a thread dump?
Created attachment 144546 [details] jstack dump I am attaching jstack dump. Hope it will help.
Thanks. It's apparent, that "JPDA Debugger" thread is waiting for a reply from the backend, but does not receive it. at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:300) - locked <0x00000000fbea5f88> (a com.sun.tools.jdi.Packet) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1036) at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:69) at com.sun.tools.jdi.JDWP$EventRequest$Set.waitForReply(JDWP.java:6769) at com.sun.tools.jdi.JDWP$EventRequest$Set.process(JDWP.java:6734) at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.set(EventRequestManagerImpl.java:202) - locked <0x00000000fbea7dc8> (a com.sun.tools.jdi.EventRequestManagerImpl$ClassPrepareRequestImpl) at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.setEnabled(EventRequestManagerImpl.java:166) - locked <0x00000000fbea7dc8> (a com.sun.tools.jdi.EventRequestManagerImpl$ClassPrepareRequestImpl) at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.enable(EventRequestManagerImpl.java:151) .... We call EventRequest.enable() and it does not return. I do not think we can do anything about this. Can you see from the logs why the response does not arrive?
Thank you! Indeed, from the call stack we can conclude that JDI have sent packet to VM and waits for response. But on my side studying JDWP logs I see that all messages from NetBeans was processed, and we are waiting for next command. By now I have no idea what is going on. I attach example.zip with short JavaME code and correspondent JDWP logs.
Created attachment 144583 [details] short JavaME code and correspondent JDWP logs
One difference that I can see is in EventRequest.Clear requests. The ok log always removes the step event, but the fail log does not remove it at the end. There are breakpoints associated with Nashorn, that add some traffic. And they are something that has changed recently and therefore could have an impact. These breakpoints are enabled/disabled around step into calls, to handle step into a JavaScript. The enabling/disabling is performed asynchronously and can thus run in parallel with other commands. In J2SE debugger this does not seem to be a problem, but can there be a problem with that in J2ME? There is a way to generate a JDWP log via -J-Dnetbeans.debugger.jditrace=16777215 Can you please try that? It seems to be more verbose. And just to reduce a chance of possible influences, can you try it without the JDWP proxy in between? Also, it can help if you could test it without the machinery with Nashorn-related breakpoints to find out if they really cause problems. This is isolated in debugger.jpda.js module, but there's a dependency on it in debugger.jpda.kit module thus it probably can not be easily removed. But the Nashorn-related breakpoints can be eliminated by going to org.netbeans.modules.debugger.jpda.js.StepIntoJSHandler and setting SCRIPT_ACCESS_METHODS to an empty array. Do you think you can test it with this modification?
Thank you very much. I have found problem on our side. In the middle of JDWP log we can see that JavaME VM got successively two identical CLASS_PREPARE "jdk.nashorn.internal.runtime.ScriptFunctionData" requests, and ignored one of them - and a seconds ago, after 110 JDWP messages passed here and there, JDI just hangs up (probably on next CLASS_PREPARE request). > can you try it without the JDWP proxy in between Actually, our JDWP proxy have JDWP protocol to communicate to NetBeans, but KDP (JDWP subset) protocol to communicate to VM - it is done to reduce footprint and increase performance for resource-constrained devices. So we can't connect VM and NetBeans directly. > generate a JDWP log via -J-Dnetbeans.debugger.jditrace=16777215 Oh, good! We already hacked VirtualMachineImpl class in jdk\lib\tools.jar to enable JDI logs :)
Thanks, I'm glad that it's resolved.