Community
Participate
Working Groups
Java Version JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 build jvmwi3260sr Eclipse hangs during debugging. This problem occurs when customer has a breakpoint and debugger reaches it. Without breakpoint it works fine. The problem is occurring when they call a JSP that uses JQuery/Ajax. So called Servlet displays a JSP that calls the same Servlet. I attached javacore. It looks like only eclipse main thread (runnable state) can potentially cause it. Stacktrace: at org/eclipse/swt/internal/win32/OS.DispatchMessageW(Native Method) at org/eclipse/swt/internal/win32/OS.DispatchMessage(Bytecode PC:7(Compiled Code)) at org/eclipse/swt/widgets/Display.readAndDispatch(Bytecode PC:7(Compiled Code)) at org/eclipse/ui/internal/Workbench.runEventLoop(Bytecode PC:9(Compiled Code)) at org/eclipse/ui/internal/Workbench.runUI(Bytecode PC:393) at org/eclipse/ui/internal/Workbench.access$4(Bytecode PC:1) at org/eclipse/ui/internal/Workbench$5.run(Bytecode PC:23) at org/eclipse/core/databinding/observable/Realm.runWithDefault(Bytecode PC:14) at org/eclipse/ui/internal/Workbench.createAndRunWorkbench(Bytecode PC:18) at org/eclipse/ui/PlatformUI.createAndRunWorkbench(Bytecode PC:2) at org/eclipse/ui/internal/ide/application/IDEApplication.start(Bytecode PC:84) at org/eclipse/equinox/internal/app/EclipseAppHandle.run(Bytecode PC:137) at org/eclipse/core/runtime/internal/adaptor/EclipseAppLauncher.runApplication(Bytecode PC:105) at org/eclipse/core/runtime/internal/adaptor/EclipseAppLauncher.start(Bytecode PC:29) at org/eclipse/core/runtime/adaptor/EclipseStarter.run(Bytecode PC:149) at org/eclipse/core/runtime/adaptor/EclipseStarter.run(Bytecode PC:183) at sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method) at sun/reflect/NativeMethodAccessorImpl.invoke(Bytecode PC:83(Compiled Code)) at sun/reflect/DelegatingMethodAccessorImpl.invoke(Bytecode PC:6) at java/lang/reflect/Method.invoke(Bytecode PC:163) at org/eclipse/equinox/launcher/Main.invokeFramework(Bytecode PC:211) at org/eclipse/equinox/launcher/Main.basicRun(Bytecode PC:114) at org/eclipse/equinox/launcher/Main.run(Bytecode PC:4) at org/eclipse/equinox/launcher/Main.main(Bytecode PC:10)
This bug needs more information - steps to reproduce, an attached sample to reproduce the problem, or more thread traces showing what the debugger is doing. The stack trace shown is the event loop and reveals no details about the debugger.
Created attachment 176159 [details] javacore Sorry, I wrote by forgot to attach javacore. I will try to get more information.
Here is some additional information: It is RAD 7.5 (based on Eclipse 3.4.2). The customer is stopping at a breakpoint in an java file. The next line of code should take customer into the different java file with a breakpoint that causes Eclipse to hang. The customer selects F8 to resume but instead of jumping to next breakpoint Eclipse freezes. Eclipse never loads the file with the breakpoint and do not stop on it. However, it looks like this code is executed because some tracing after this breakpoint is displayed in console. Eclipse is unresponsive during this freeze. The customer's machine overall continues to slow down to the point where everything on the machine becomes slow and unresponsive. When customer terminates the WAS processes, Eclipse becomes responsive again. Without breakpoint in this place it works (in debug mode). It is not possible to provide sample code to reproduce the issue. I will try to get some more traces for debugger.
This issue is easily workaroundable by using external browser. This makes SWT browser the main suspect. When you look at the javacore main thread, you will find: at org/eclipse/swt/internal/win32/OS.DispatchMessageW(Native Method) at org/eclipse/swt/internal/win32/OS.DispatchMessage(Bytecode PC:7(Compiled Code)) at org/eclipse/swt/widgets/Display.readAndDispatch(Bytecode PC:7(Compiled Code)) which means the main loop processes some event, but instead of java stack, you will find the native one: KiFastSystemCallRet+0x0 (0x7C90E514 [ntdll+0xe514]) GetLastInputInfo+0x105 (0x7E4195F9 [USER32+0x95f9]) MsgWaitForMultipleObjects+0x1f (0x7E4196A8 [USER32+0x96a8]) FindMimeFromData+0x561 (0x78156DBB [urlmon+0x26dbb]) FindMimeFromData+0x5c3 (0x78156E1D [urlmon+0x26e1d]) GetIDNFlagsForUri+0x1fed (0x78152314 [urlmon+0x22314]) DllUnregisterServer+0x68b44 (0x74A25970 [msxml3+0xa5970]) DllUnregisterServer+0x6753d (0x74A24369 [msxml3+0xa4369]) DispCallFunc+0xc3 (0x77135CD9 [OLEAUT32+0x15cd9]) DispCallFunc+0x6d2 (0x771362E8 [OLEAUT32+0x162e8]) DllUnregisterServer+0xdcc (0x749BDBF8 [msxml3+0x3dbf8]) 0x749BDE46 0x749D037D [ ...many memory addresses... ] GetDC+0x6d (0x7E418734 [USER32+0x8734]) [ ...many memory addresses... ] In my opinion, the internal browser is waiting for some data (ajax) needed for completing some operation, but this data will not arrive because the server has been stopped for debugging. Silenio, Darin, could you comment?
(In reply to comment #4) > Silenio, Darin, > could you comment? I will defer to Silenio as the browser looks like the main suspect.
Grant, could you investigate this problem? The stacktrace does not help much. It only indicates that SWT is dispatching an event. If DispatchMessage() does not return until the breakpoint is resume, I do not see any way this can be fixed since the user will not be able to resume the thread (the UI thread is not responding to events). We need steps to reproduce the problem.
The embedded WebBrowser control is spec'd to run in-process, and this is how SWT embeds it, so it's quite possible that the guess in comment 6 is what's happening. I know that an out-of-process browser control ships with some IBM products, I'm not sure if RAD is one of them. If it is, it would be helpful to see if it avoids this problem. As Silenio says, it may not be possible to make this case work in a browser that's running in-process. Is the customer able to reduce some of the involved files to make a basic case that reproduces the problem and does not contain anything they're unable to share?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Happens to me 4 to 5 times daily and is completely unworkable at this point. It can work for hours and then happen 3 times back to back. When it happens it will stay hung forever. Have to kill the windows process as well as kill OpenJDK process since my wildfly is up and running. There is no way to "reproduce it". It happens when looking at debug variables, stepping through code or removing breakpoints. It is too inconsistent to say its one thing that makes it happen. Any thoughts to what I can capture after the hang has happened and before I kill the process. I have completely formatted my PC and re-installed. 2020-03 still has the problem.
Just updated my 4.16 eclipse to 4.17. Debug does not work completely: if there is a breakpoint and the debugger reach it - nothing happens(all debug buttons remain inactive). Happens for plain junit 5 test and when running Spring Boot app. Java 11, windows, no additional plugins related to java development(there is kotlin plugin though)
Here some logs: !ENTRY org.eclipse.debug.core 4 125 2020-09-17 18:12:06.939 !MESSAGE An exception occurred while dispatching debug events. !STACK 0 java.lang.VerifyError: Expecting a stackmap frame at branch target 23 Exception Details: Location: org/eclipse/jdt/internal/debug/core/model/JDIStackFrame.exists()Z @7: aload_0 Reason: Expected stackmap frame at this location. Bytecode: 0000000: 2ab4 0052 594c c22a b400 3d02 9f00 0704 0000010: a700 0403 2bc3 ac2b c3bf Exception Handler Table: bci [7, 22] => handler: 23 bci [23, 25] => handler: 23 at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:658) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:718) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getTopStackFrame(JDIThread.java:1401) at org.eclipse.debug.internal.ui.contexts.LaunchSuspendTrigger.notifySuspend(LaunchSuspendTrigger.java:105) at org.eclipse.debug.internal.ui.contexts.LaunchSuspendTrigger.handleDebugEvents(LaunchSuspendTrigger.java:87) at org.eclipse.debug.core.DebugPlugin$EventNotifier.run(DebugPlugin.java:1201) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.debug.core.DebugPlugin$EventNotifier.dispatch(DebugPlugin.java:1235) at org.eclipse.debug.core.DebugPlugin$EventDispatchJob.run(DebugPlugin.java:465) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
(In reply to Bohdan Z from comment #10) > Just updated my 4.16 eclipse to 4.17. > Debug does not work completely: if there is a breakpoint and the debugger > reach it - nothing happens(all debug buttons remain inactive). Happens for > plain junit 5 test and when running Spring Boot app. > > Java 11, windows, no additional plugins related to java development(there is > kotlin plugin though) Bohdan, this is a different issue, unrelated to this bug, see bug 567081.
