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.
Summary: | Debugging JavaME: debugging hangs up after F7 (step into) | ||
---|---|---|---|
Product: | debugger | Reporter: | BorisUlasevich |
Component: | Java | Assignee: | Martin Entlicher <mentlicher> |
Status: | RESOLVED INCOMPLETE | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 8.0 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
source, log, screenshot
jstack dump short JavaME code and correspondent JDWP logs |
Description
BorisUlasevich
2014-01-28 14:54:55 UTC
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. |