Attaching netbeans deugger in Windows



In Linux I have been attaching Netbeans debugger for a long time.
I go into a command box and use:

ilan@ilan-Lenovo-G585:~/$ ./ImageJ-linux64 --debugger=8800
Java HotSpot™ 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot™ 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
Listening for transport dt_socket at address: 8800

I attach the debugger and begin to work.
The equivalent process in Windows fails.
In Linux the command remains active and ^C will exit Fiji.
In Windows7 it will fire up Fiji fine but the command box command will finish and return to the c:> prompt. When I try to connect the debugger I will get a message that the connection is refused.

What is the proper way to attach a debugger to a running Fiji instance?


I would guess that you started the debugger with the wrong options on Windows or it is a firewall problem.

Maybe the documentation helps:

Quite similar I created a debugging tutorial for my application based on Eclipse to debug dynamic compiled Java code. Maybe it helps to identify a missing step or command line argument because the steps are similar to Netbeans using the same architecture:


Thanks for the reply. I looked carefully at your video and I think it describes what I am doing on a daily basis.

I can start Netbeans to debug my code and put breakpoints to my heart’s content. That works very well.
What I am doing is starting an instance of ImageJ in debug mode. Then I send it off to run my plugin, capture it at a breakpoint, and I can find whatever the problem is.

Here I want to do something slightly different. I want to start the nominal version of Fiji in exactly the same way my users do. Then I attach the Netbeans debugger to the nominal software as the end user is actually using it.
The documentation says to use: /ImageJ-linux64 --debugger=8000

Note that it is using linux64 in the example. In fact Linux works perfectly well. As I wrote in the first part of the thread, the command box shows that it is still in command and ImageJ is listening for an attached debugger.

In Windows it seems to be to be broken (or it never actually worked - don’t know which). The command box does indeed start Fiji, but then it returns to the command prompt without saying it is listening. When I try to attach the debugger, it say connection refused. That makes some sense if ImageJ isn’t really listening for a connection.

What I actually use in Windows is
C:\>ImageJ-win32.exe --debugger=8800

C:\>ImageJ-win32.exe -agentlib:jdwp=server=y,suspend=y,transport=dt_sock
et,address=localhost:8800 –


There are 2 different versions of the command string and I tried them both. The first one is similar to the linux version, except using ImageJ-win32.exe, and I chose a slightly different port as well. This one will return to the command prompt as soon as Fiji is running. Trying to attach the Netbeans debugger will result in connection refused.

Then I tried the second version. That basically hung in an endless loop, but didn’t allow me to attach a debugger either. I basically killed the Fiji process and then it returned to the command prompt.

It is a VERY nice feature that I can attach a debugger from Netbeans or Eclipse to the nominal software. It is a real pity that it doesn’t seem to work in Windows (or at least I can’t figure out how to do it).


More details and tips (Eclipse but useful):

Also check if you firewall is blocking the connection or another process is still active which blocks the connection.

See also:

Also I wonder why you use -- at the end of the second command instead of:

ImageJ-win32.exe -agentlib:jdwp=server=y,suspend=y,transport=dt_socket,address=localhost:8000


Thanks for helping to try and solve this problem.
I also saw the “–” at the end of the command and wondered why it appeared this way in the documentation.
I figured I’d better play safe and go by the rules.

I modified it to
C:\>ImageJ-win32.exe -agentlib:jdwp=server=y,suspend=n,transport=dt_sock


Now it acts the same way as the command I use in linux - it fires up Fiji and then returns to the command prompt.
I have a gut feeling that ImageJ-win32.exe is simply ignoring the parameter string. ImageJ-linux64 stops and listens for the debugger. Windows returns immediately to the command prompt. In my mind that looks like a big difference.
On the Netbeans side, it looks very similar to what you see in Eclipse, which makes sense.

I don’t think I have any network problems as I am running both Netbeans and Fiji on exactly the same machine - localhost. This is definitely NOT remote debugging, but you can call localhost “remote” and pretend it is.

It still seems to me that the problem is on the Fiji side as it fails to listen for an attached debugger. Something seems to be wrong with ImageJ-win32.exe.

In any case there is some progress in that now both command strings behave the same.