TestNG hangs in debug mode (dreaded 57%) #55

ghost opened this Issue Mar 12, 2012 · 23 comments


None yet
ghost commented Mar 12, 2012

Ever since I upgraded the testng-eclipse plugin, I hang at 57% when debugging a test (any test) in Eclipse. The last entry in the error log appears to be:

java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.java.product

Mon Mar 12 17:44:07 EDT 2012

java.net.SocketTimeoutException: Accept timed out
at java.net.TwoStacksPlainSocketImpl.socketAccept(Native Method)
at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:183)
at java.net.ServerSocket.implAccept(ServerSocket.java:522)
at java.net.ServerSocket.accept(ServerSocket.java:490)
at org.testng.remote.strprotocol.BaseMessageSender.initReceiver(BaseMessageSender.java:128)
at org.testng.eclipse.ui.TestRunnerViewPart.startTestRunListening(TestRunnerViewPart.java:402)
at org.testng.eclipse.TestNGPlugin.connectTestRunner(TestNGPlugin.java:215)
at org.testng.eclipse.TestNGPlugin$2.run(TestNGPlugin.java:203)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)

I am running:

Eclipse Indigo Service Release 2 (build 20120216-1857)
testng-eclipse plugin

I do have TestNG 6.4 declared as a Maven dependency (test scope) within my project. I read online that there can be a conflict between the project and plugin's versions of TestNG. However, both are at 6.4 (verified this in both Maven and Eclipse) for this project.

Any thoughts?

Thanks so much!

  • Saish
cbeust commented Mar 12, 2012

Does the problem go away if you remove this Maven dependency? Are you sure you don't have any other testng.jar that could be causing this problem?

ghost commented Mar 12, 2012

Thank you for the quick reply!

Yes, there are TestNG dependencies on the classpath. One we explicitly provide (6.4), the other is from powermock-modue-testng (which transitively brings in 6.2).

I cannot remove these from our POM for two reasons. First, it breaks Eclipse. There are a number of "type org.testNg.IHookable cannot be resolved. It is indirectly referenced from required .class files." (I launched with -clean for Eclipse and did a Maven refresh project configuration and clean build just for paranoia sake).

Second, it breaks the Maven command line build, which uses TestNG for both unit and integration tests.

The plugin did appear to work fine before this last upgrade. (Sorry, I do not remember my prior version, which I know is notably unhelpful). Invoking a test via run rather than debug works fine.

  • Saish
ghost commented Mar 12, 2012

Two other items that may or may not help. In the other threads I noticed here, there was some debate about whether the UI thread is locked as a result. At least for me, it appears so. Eclipse becomes unusable and requires a kill from the O/S.

Leaving in the explicit 6.4 from our POM causes the error whether the 6.2 dependency is excluded or not.


cbeust commented Mar 12, 2012

The problem most likely comes from the 6.2 jar. However, by default, the Eclipse plug-in should be using its own internal jar file, so I suspect that maybe another plug-in is messing with the way it configures its classpath. Can you confirm that the plug-in works fine on a brand new project?

After that, maybe you can try to update the 6.2 dependency to 6.4 and see what happens?

ghost commented Mar 13, 2012

Thanks for the suggestions. I had actually tried a number of permutations. These included removing all TestNG dependencies (broke Eclipse and Maven builds). Matching the TestNG version in the POM with the version of the plug-in (with exclusions for any conflicting dependencies ala the 6.2 version to which you alluded). None of those helped.

In the end, the only thing that worked was to create an entirely new workspace. I know that probably does not help anyone who later stumbles on this thread for future help or you to diagnose the issue. At least it is not anything at a project level, so most developers should be able to recover from this.

Glad everything is working, and love writing tests in TestNG. Thank you for your help.

  • Saish
@ghost ghost closed this Mar 13, 2012
cbeust commented Mar 13, 2012

Thanks for reporting back and glad to hear everything's working now.


I don't think its fixed at all, I experienced the exact same issues as saish, uninstalling other plugins I'd updated at the same time thinking they were somehow interfering.

Per the above 'solution' I moved the project to a new workspace and then debugging worked for a while then the issue came back again. Reviewing the error log reveals the same socket timeout stack trace as he showed above.

Whatever the issue is, it shouldn't lock up the whole UI, forcing the user to kill Eclipse.


Furthermore, I seem unable to revert back to earlier versions. Trying to install any version other than the latest brings up an error during installation:

An error occurred while collecting items to be installed
session context was:(profile=epp.package.rcp, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
Artifact not found: osgi.bundle,org.testng.eclipse,
Artifact not found: org.eclipse.update.feature,org.testng.eclipse,

Any suggestions on a way around this?

cbeust commented Mar 16, 2012

Can you try a different older versions? Pick one from here: http://beust.com/eclipse-old/

bhaifive commented Aug 1, 2012

I am very thankful to saish and cbeust for the solution. I went through the similar issue with eclipse which got stuck at 57% when run in debug mode. I tried every thing, deleting eclipse, reinstalling diff versions, changing memory in eclipse.ini and all, but nothing helped.
The only thing helped was to create entirely new workspace. Thanks again, I got things worked after 2 days :-)


I had this issue too, Eclipse hangs at 57% in debug mode with TestNG tests. i checked version mismatch, created new workspace, deleted and reimported projects and nothing worked. Then I increased the MaxPermSize to 512m and the issues is fixed. I'm using Spring Tools Suite 2.9.2.RELEASE and TestNG/eclipse plugin 6.5.2.

Btw, this freezes the GUI and the only way is to kill the process ans start STS again.

I changed the STS.ini file, the parameter:

Now it's working fine!!!


I am facing the same issue.I tried with new workspace also but in vain.

Below is my configuration but still getting the same issues.console message says "launching abc class (57 % ) and it hangs.

1.Java version - jdk-7u7-windows-x64
2.Eclipse version -64 bit eclipse - Kepler
3.Testng version - 6.8.0
4.Selenium - 2.28.0 ( java version)

Let me know if it needs any other configuration change.


cbeust commented Jan 21, 2013

You probably have an old testng.jar file on your class path. Can you try on a clean workspace?


tried with clean workspace but facing smae issue

ulfreich commented Feb 5, 2013

Hi to all,

I was having the 57% freeze issue debugging on windows. Tried checking my firewall, cleaning eclipse, creating a new workspace, updating to the latest version, but nothing worked. After some surfing, I got a hint it could indeed be a port problem, so I effectively diagnosed it:

  • The first launch worked fine: eclipse started listening on, let's say, port 10000 and the testng client connected succesfully to that port. When testing was done, the port remained open!
  • In the second launch eclipse started listening on port 10001 but quickly died (I suppose, because it already was listening on port 10000), but the client tried forever to connect to 10001 causing the freeze.

In the end, I found this code by denyska:

I compiled the TestRunnerViewPart class and replaced the generated .class files on the eclipse plugins folder. Now it finally works, like a charm. Just wanted to let you know.



I just realized what was causing the issue. I set a breakpoint in TestNg class inside the jar. I don't think you need to re-create a new workspace. Just remove all breakpoints and try again :)


THANK YOU spammeru!!!

This was making me crazy. It's not the first time this has happened to me, and I have no idea why it suddenly started working again last time. It maks sense that resetting the workspace would "fix" the problem - it clears breakpoints.

This is especially frustrating because it happens when you are setting breakpoints... in other words, when you need the debugger.

In my case, disabling the ArrayIndexOutOfBoundException exception fixed the problem.


Just in case someone comes across this issue: In my case it was sufficient to delete the folder WORKSPACE_DIR/.metadata/.plugins/org.testng.eclipse/ and restart Eclipse instead of re-creating the complete workspace.


Facing the Same issue. Creating new Workspace also ddidnt help. Totally Blocked. Need help urgently

Eclipse error Log

!ENTRY org.testng.eclipse 1 0 2013-07-10 13:09:55.180
!MESSAGE [TestNGLaunchConfigurationDelegate] Launching:
Classpath: /C:/Users/Dell/Downloads/eclipse-jee-juno-win32-x86_64/eclipse/plugins/org.testng.eclipse_6.8.6.20130607_0745/lib/testng.jar C:\Users\Dell\workspace\FirstProject\bin C:\Users\Dell\Downloads\eclipse-jee-juno-win32-x86_64\eclipse\plugins\org.testng.eclipse_6.8.6.20130607_0745\lib\testng.jar
VMArgs: -ea
Class: org.testng.remote.RemoteTestNG
Args: -serport 52230 -d C:\Users\Dell\workspace\FirstProject\test-output C:\Users\Dell\AppData\Local\Temp\testng-eclipse-935584169\testng-customsuite.xml
java -ea -classpath /C:/Users/Dell/Downloads/eclipse-jee-juno-win32-x86_64/eclipse/plugins/org.testng.eclipse_6.8.6.20130607_0745/lib/testng.jar:C:\Users\Dell\workspace\FirstProject\bin:C:\Users\Dell\Downloads\eclipse-jee-juno-win32-x86_64\eclipse\plugins\org.testng.eclipse_6.8.6.20130607_0745\lib\testng.jar org.testng.remote.RemoteTestNG -serport 52230 -d C:\Users\Dell\workspace\FirstProject\test-output C:\Users\Dell\AppData\Local\Temp\testng-eclipse-935584169\testng-customsuite.xml

!ENTRY org.testng.eclipse 4 4 2013-07-10 13:10:00.276
java.net.SocketTimeoutException: Accept timed out
at java.net.DualStackPlainSocketImpl.waitForNewConnection(Native Method)
at java.net.DualStackPlainSocketImpl.socketAccept(Unknown Source)
at java.net.AbstractPlainSocketImpl.accept(Unknown Source)
at java.net.PlainSocketImpl.accept(Unknown Source)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at org.testng.remote.strprotocol.BaseMessageSender.initReceiver(BaseMessageSender.java:128)
at org.testng.eclipse.ui.TestRunnerViewPart.startTestRunListening(TestRunnerViewPart.java:373)
at org.testng.eclipse.TestNGPlugin.connectTestRunner(TestNGPlugin.java:213)
at org.testng.eclipse.TestNGPlugin$2.run(TestNGPlugin.java:201)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4144)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
at org.eclipse.equinox.launcher.Main.main(Main.java:1414)


Thanks spammeru. Removing the Breakpoints on the class files did the charm. Thanks Again.


Ran into the same problem and the breakpoint reference was the hint I needed. I had left an exception breakpoint set for both caught and uncaught exceptions and TestNG must have been catching and handling the reference internally. Unfortunately this caused Eclipse to deadlock with no hint as to why.

SidArc commented Jan 3, 2015

I am also facing the same issue, with no solution still, I am just trying to run a simple TestNG Class using TestNG Test and it is causing the Eclipse to Freeze, I have tried almost every solution talked above, can anyone help me with the solution to this issue.

In the above mentioned comments I have read that removing the breakpoints from TestNG class helped, are we here referring to the class file in the testng-6.8.5 jar or in the class file that we have created because I do not have any breakpoints in my class file but still I am facing this issue.

Can someone help me.


Thanks spammeru !!
Removing break point from jar worked :)

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment