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.

Bug 195298 - Can not debug JUnit test in Module project
Summary: Can not debug JUnit test in Module project
Status: RESOLVED WORKSFORME
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 7.0
Hardware: PC Linux
: P3 normal (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-10 15:21 UTC by artisan
Modified: 2011-02-14 15:20 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description artisan 2011-02-10 15:21:16 UTC 
Getting this error when starting the debugger:

ERROR: transport error 202: connect failed: Connection refused
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]
Java Result: 134

When trying to debug a unit test in a Netbeans Module project. Debugging is no problem for a classic- or Maven project.

As such, I don't think there's a network-related problem here...
Comment 1 artisan 2011-02-10 18:57:12 UTC 
It seems to work on my other computer. The only difference is the JVM. 

$ java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)

On my laptop - where it fails - it's 1.6.0_23. Maybe that's an indicator ?
Comment 2 Jesse Glick 2011-02-11 23:09:52 UTC 
Sorry, no clue how to reproduce. Possibly an environmental issue. JDK 6u23 should be fine but perhaps 32- vs. 64-bit VMs are involved.
Comment 3 artisan 2011-02-11 23:44:14 UTC 
Maybe reproduction would start by creating a module project, adding a junit 4 test to it and try to debug it ? ( using visualvm 131 as the platform btw)

And if that fails to reproduce the problem, ask the reporter for some more details ?

And just *maybe* not slamming the door shut in the face of somebody who takes time to report a problem ?
Comment 4 Jesse Glick 2011-02-14 15:20:28 UTC 
(In reply to comment #3)
> Maybe reproduction would start by creating a module project, adding a junit 4
> test to it and try to debug it ? ( using visualvm 131 as the platform btw)

Not sure what the "131" refers to, but I just tried making a module project using lib/visualvm from JDK 6u23 on Linux (with org.netbeans.libs.junit4 added), made a unit test, and successfully debugged it.

> ask the reporter for some more details?

If you have some more details that would enable another party to reproduce the problem, by all means give them and reopen. For certain kinds of bugs (e.g. a NullPointerException) it is often possible to attempt a fix without being able to reproduce the bug and thus verify the solution; this bug does not fall in that category, unfortunately. No purpose is served by having a report be open that the assignee cannot work on, and the current WORKSFORME status simply reflects that fact.

You can try doing fresh installations of NetBeans and the JDK, comparing different computers and NB/JDK versions, etc. Judging by the error message my guess is that the problem is not in NetBeans code, though it is impossible to be sure.