Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug with breakpoint in java.util.Properties causes 'Timeout while trying to contact RemoteTestNG' #155

Closed
stephenhartley opened this issue Jun 14, 2015 · 6 comments

Comments

@stephenhartley
Copy link

I have a simple testng test which uses java.util.Properties.

I have set a breakpoint in the JDK source for java.util.Properties, start debug, breakpoint is triggered, but then the 'Timeout while trying to contact RemoteTestNG' modal below is shown and on pressing OK, nothing further happens.

image

Debug output is:

[RemoteTestNG] Invoked with -serport 58295 -d C:\steve\githubrepos\camel\test-output C:\Users\steve\AppData\Local\Temp\testng-eclipse--535199138\testng-customsuite.xml 
[BaseMessageSender] Waiting for Eclipse client on localhost:58295

Stack at this point shows:

AlchemetricsFilenameTest.testProperties [TestNG]    
org.testng.remote.RemoteTestNG at localhost:52087   
    Thread [main] (Suspended (breakpoint at line 166 in Properties))    
        owns: Properties  (id=32)   
        owns: Class<T> (java.util.TimeZone) (id=19) 
        owns: JarFile  (id=33)  
        owns: URLClassPath  (id=34) 
        owns: Object  (id=35)   
        Properties.setProperty(String, String) line: 166    
        System.setProperty(String, String) line: 796    
        TimeZone$1.run() line: 684  
        TimeZone$1.run() line: 681  
        AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]  
        TimeZone.setDefaultZone() line: 681 
        TimeZone.getDefaultRef() line: 636  
        Date.<init>(int, int, int, int, int, int) line: 254 
        ZipUtils.dosToJavaTime(long) line: 74   
        JarFile(ZipFile).getZipEntry(String, long) line: 570    
        JarFile(ZipFile).getEntry(String) line: 313 
        JarFile.getEntry(String) line: 240  
        JarFile.getJarEntry(String) line: 223   
        JarFile.getManEntry() line: 494 
        JarFile.checkForSpecialAttributes() line: 553   
        JarFile.hasClassPathAttribute() line: 518   
        JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(JarFile) line: 37    
        URLClassPath$JarLoader.getClassPath() line: 1149    
        URLClassPath.getLoader(int) line: 495   
        URLClassPath.getNextLoader(int[], int) line: 457    
        URLClassPath.getResource(String, boolean) line: 211 
        URLClassLoader$1.run() line: 365    
        URLClassLoader$1.run() line: 362    
        AccessController.doPrivileged(PrivilegedExceptionAction<T>, AccessControlContext) line: not available [native method]   
        Launcher$AppClassLoader(URLClassLoader).findClass(String) line: 361 
        Launcher$AppClassLoader(ClassLoader).loadClass(String, boolean) line: 424   
        Launcher$AppClassLoader.loadClass(String, boolean) line: 331    
        Launcher$AppClassLoader(ClassLoader).loadClass(String) line: 357    
        LauncherHelper.checkAndLoadMain(boolean, int, String) line: 495 

Debugging with a breakpoint in my own source code rather than the JDK source works as expected, it only seems to be a problem when the breakpoint is in JDK source.

I'm using Luna Service Release 2 (4.4.2) Build id: 20150219-0600 with the testng plugin version 6.9.5.201506120235. My project has a maven dependency on testng 6.9.4. JDK version 1.8.0_45.

I tried unchecking use project testng jar as suggested by the modal but this did not fix the problem.

There is some related history on #148 with comments from @cbeust:

The Eclipse plug-in launches RemoteTestNG as a separate process but because of the break point, RemoteTestNG doesn't take off so it never opens a socket. Eventually, the plug-in's attempt at connecting on this socket time out.

and @missedone:

yes, it's a bug, please go ahead to create a new issue to track this.

@missedone
Copy link
Collaborator

OK, it's gonna be interesting now.

after digging into the code, it turned out that break point at java.util.Properties is a special case, for example,

    @Test
    public void testProperties() throws Exception {
        Properties prop = new Properties();
    }

if put the break point at java.util.Properties.Properties(Properties), can get the error dialog 'Timeout while trying to contact RemoteTestNG' and the stack trace as below:

org.testng.remote.RemoteTestNG at localhost:51508   
    Thread [main] (Suspended (breakpoint at line 144 in Properties))    
        owns: InetAddress$Cache  (id=363)   
        Properties.<init>(Properties) line: 144 
        Properties.<init>() line: 135   
        Security.initialize() line: 76  
        Security.access$000() line: 47  
        Security$1.run() line: 69   
        Security$1.run() line: 67   
        AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]  
        Security.<clinit>() line: 67    
        InetAddressCachePolicy$1.run() line: 94 
        InetAddressCachePolicy$1.run() line: 92 
        AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]  
        InetAddressCachePolicy.<clinit>() line: 90  
        InetAddress$Cache.getPolicy() line: 751 
        InetAddress$Cache.put(String, InetAddress[]) line: 763  
        InetAddress.cacheInitIfNeeded() line: 842   
        InetAddress.getCachedAddresses(String) line: 875    
        InetAddress.getAllByName0(String, InetAddress, boolean) line: 1244  
        InetAddress.getAllByName(String, InetAddress) line: 1164    
        InetAddress.getAllByName(String) line: 1098 
        InetAddress.getByName(String) line: 1048    
        InetSocketAddress.<init>(String, int) line: 220 
        Socket.<init>(String, int) line: 208    
        SerializedMessageSender(BaseMessageSender).connect() line: 58   
        MessageHub.connect() line: 32   
        RemoteTestNG.run() line: 84 
        RemoteTestNG.initAndRun(String[], CommandLineArgs, RemoteArgs) line: 204    
        RemoteTestNG.main(String[]) line: 175   

the whole stack trace showing RemoteTestNG is still initializing, the socket not yet listen and it's paused by the break point, while org.testng.eclipse.ui.TestRunnerViewPart.startTestRunListening(IJavaProject, String, int, ILaunch) in other thread process asking for the connect but failed.

so it's OK as long as you don't add break point at the code that used by RemoteTestNG initilization, for example, below case is OK:

    @Test
    public void testPaths() throws Exception {
        Path home = Paths.get(System.getProperty("user.home"));
    }

add break point at java.nio.file.Paths.get(String, String...) won't get any problem.

though the root cause is quite clear, I have no good idea to fix this at the moment.
so let me think about this for awhile:)

@cbeust
Copy link
Collaborator

cbeust commented Jun 14, 2015

Fascinating :-)

I wonder if there's a way to launch processes from an Eclipse plug-in while
telling Eclipse "Do not apply breakpoints to this process"?

Cédric

On Sun, Jun 14, 2015 at 8:10 AM, Nick Tan notifications@github.com wrote:

OK, it's gonna be interesting now.

after digging into the code, it turned out that break point at
java.util.Properties is a special case, for example,

@Test
public void testProperties() throws Exception {
    Properties prop = new Properties();
}

if put the break point at java.util.Properties.Properties(Properties),
can get the error dialog 'Timeout while trying to contact RemoteTestNG' and
the stack trace as below:

org.testng.remote.RemoteTestNG at localhost:51508
Thread [main](Suspended %28breakpoint at line 144 in Properties%29)
owns: InetAddress$Cache (id=363)
Properties.(Properties) line: 144
Properties.() line: 135
Security.initialize() line: 76
Security.access$000() line: 47
Security$1.run() line: 69
Security$1.run() line: 67
AccessController.doPrivileged(PrivilegedAction) line: not available [native method]
Security.() line: 67
InetAddressCachePolicy$1.run() line: 94
InetAddressCachePolicy$1.run() line: 92
AccessController.doPrivileged(PrivilegedAction) line: not available [native method]
InetAddressCachePolicy.() line: 90
InetAddress$Cache.getPolicy() line: 751
InetAddress$Cache.put(String, InetAddress[]) line: 763
InetAddress.cacheInitIfNeeded() line: 842
InetAddress.getCachedAddresses(String) line: 875
InetAddress.getAllByName0(String, InetAddress, boolean) line: 1244
InetAddress.getAllByName(String, InetAddress) line: 1164
InetAddress.getAllByName(String) line: 1098
InetAddress.getByName(String) line: 1048
InetSocketAddress.(String, int) line: 220
Socket.(String, int) line: 208
SerializedMessageSender(BaseMessageSender).connect() line: 58
MessageHub.connect() line: 32
RemoteTestNG.run() line: 84
RemoteTestNG.initAndRun(String[], CommandLineArgs, RemoteArgs) line: 204
RemoteTestNG.main(String[]) line: 175

the whole stack trace showing RemoteTestNG is still initilizing, the
socket not yet listen and it's paused by the break point, while org.testng.eclipse.ui.TestRunnerViewPart.startTestRunListening(IJavaProject,
String, int, ILaunch) in other thread asking for the connect but failed.

so it's OK as long as you don't add break point at the code that used by
RemoteTestNG initilization, for example, below case is OK:

@Test
public void testPaths() throws Exception {
    Path home = Paths.get(System.getProperty("user.home"));
}

add break point at java.nio.file.Paths.get(String, String...) won't get
any problem.

though the roo cause is quite clear, I have no good idea to fix this at
the moment.
so let me think about this for awhile:)


Reply to this email directly or view it on GitHub
#155 (comment)
.

@stephenhartley stephenhartley changed the title Debug with breakpoint in JDK source causes 'Timeout while trying to contact RemoteTestNG' Debug with breakpoint in java.util.Properties causes 'Timeout while trying to contact RemoteTestNG' Jun 14, 2015
@stephenhartley
Copy link
Author

As a workaround, I've been doing this: suspend all breakpoints except for one at the first line of the first test method to run. Launch the eclipse debug. When the breakpoint triggers, enable the remaining breakpoints.

Not a solution, but a reasonable workaround until a fix becomes available.

@missedone
Copy link
Collaborator

hi guys, new testng eclipse plugin build 6.9.5.201508210528 was just out, could you update to this version and verify if this issue resolved, thanks

@missedone
Copy link
Collaborator

this issue should be fixed in PR #166, let's close it

@cbeust
Copy link
Collaborator

cbeust commented Sep 27, 2015

I'll let you close it yourself now that you can :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants