NetBeans debugger: suspend and see current stack trace how?

[Nelson Ashton]

At my previous shop we all used Eclipse. Now we all use NetBeans.

One thing I found very handy in Eclipse was that you could debug a
program, and if it froze or otherwise misbehaved, you could hit pause
and look at where all of the current threads were in the program. This
was useful for diagnosing deadlocks (you'd find threads sitting on
synchronized (foo) lines) and infinite loops (the thread that was
supposed to be making progress would be sitting in the particular loop
that it was never escaping from).

Now I have a similar problem to debug, but I can't for the life of me
figure out how to coax NetBeans into coughing up a report on where all
currently-executing threads got suspended after hitting the pause
button. The only apparent way to get thread information, so far, is to
guess at a possible deadlock/infinite loop site, put a breakpoint
there, run the app, and pray; then move the breakpoint to another
guessed location and run again; and so on possibly all bloody day.

There surely must be a better way?

 

[Mark Space]

This doesn't directly answer your question but it might help. Scroll
down or search for "thread dump".

<http://jroller.org/nbprofiler/>

 

[Nelson Ashton]

This doesn't directly answer your question but it might help.  Scroll
down or search for "thread dump".

<http://jroller.org/nbprofiler/>

Thanks, but that only got me part of the way there.

With the profiler, I can see that when I trigger the hang, AWT-
EventQueue-0 turns green and stays that way, meaning that some long-
running activity is occurring on the EDT and hanging the UI, and that
it's not waiting on a monitor (which would have turned it red).

What I still don't know how to do is actually get a thread dump, with
a stack trace for a specific thread or for each running thread. The
obvious, poking around in menus and right-clicking the thread of
interest, hasn't revealed anything.

 

[Mark Space]

Thanks, but that only got me part of the way there.

With the profiler, I can see that when I trigger the hang, AWT-
EventQueue-0 turns green and stays that way, meaning that some long-
running activity is occurring on the EDT and hanging the UI, and that
it's not waiting on a monitor (which would have turned it red).

What I still don't know how to do is actually get a thread dump, with
a stack trace for a specific thread or for each running thread. The
obvious, poking around in menus and right-clicking the thread of
interest, hasn't revealed anything.

I'm looking myself at it still too (no luck yet, although there might be
such a feature in NB 6.5), but if you got that far, can you profile your
own methods and see which one is sucking all the CPU resources? Let it
go for a while and then take a snap-shot, the method invocations at the
top of the CPU time graph should be the first ones to look at.

 

[Lew]

At my previous shop we all used Eclipse. Now we all use NetBeans.

Congratulations on the upgrade.

One thing I found very handy in Eclipse was that you could debug a
program, and if it froze or otherwise misbehaved, you could hit pause
and look at where all of the current threads were in the program. This
was useful for diagnosing deadlocks (you'd find threads sitting on
synchronized (foo) lines) and infinite loops (the thread that was
supposed to be making progress would be sitting in the particular loop
that it was never escaping from).

NetBeans has this feature.

Now I have a similar problem to debug, but I can't for the life of me
figure out how to coax NetBeans into coughing up a report on where all
currently-executing threads got suspended after hitting the pause
button. The only apparent way to get thread information, so far, is to
guess at a possible deadlock/infinite loop site, put a breakpoint
there, run the app, and pray; then move the breakpoint to another
guessed location and run again; and so on possibly all bloody day.

There is a window in the Debugger view that has all the threads
listed. If you click on each one in that window, it will navigate to
the corresponding source in the source window.

 

[Nelson Ashton]

Congratulations on the upgrade.

There is a window in the Debugger view that has all the threads
listed.  If you click on each one in that window, it will navigate to
the corresponding source in the source window.

This appears to be describing Eclipse, not NetBeans.

 

[Mark Space]

This appears to be describing Eclipse, not NetBeans.

Ah ha! Windows -> Debugging -> Threads

It's not open by default. I still have figured out how to use it to do
what you want, but it's there, and it will take me to a source file.
(In the Java API, for the one I checked.)

 

[Mark Space]

Ah ha! Windows -> Debugging -> Threads

It's not open by default. I still have figured out how to use it to do
what you want, but it's there, and it will take me to a source file. (In
the Java API, for the one I checked.)

Try right-clicking on the thread, select "Make Current" then go to the
Call Stack window, click on a likely looking method name....

This took me to a method I know spends most of it's time in a wait() call.

 

[Nelson Ashton]

Try right-clicking on the thread, select "Make Current" then go to the
Call Stack window, click on a likely looking method name....

This took me to a method I know spends most of it's time in a wait() call..

Thank you. This will come in handy in the future.

 

[Nelson Ashton]

What a ludicrous response.

Why? Eclipse is the IDE with separate coding and debugging
perspectives, where the latter includes a thread monitor by default.

 

[Lew]

Why? Eclipse is the IDE with separate coding and debugging
perspectives, where the latter includes a thread monitor by default.

Because my answer was about NetBeans. It was ludicrous to take an
answer about NetBeans and say that it must apply to something else.
My answer was about NetBeans. I was talking about NetBeans (6.5).
Not Eclipse. As my statement, "NetBeanas has this feature" might have
clued you into. Should have clued you into. As should have the fact
that I was answering a question about NetBeans's features. Duhy.

So, again, here's the information I was trying to give you - NetBeans
has the feature that when you suspend a program in the debugger, there
is a window with all the extant threads visible in the debugger view.
If you (double-)click on one of the threads in that window, actually
on one of the expanded items within that thread, it will take you to
the corresponding line of source in the editor window, if available.

Note that the debugger view in NetBeans is not a separate
"perspective" but merely the view you have when you invoke the
debugger. Invoking the debugger automatically brings up certain
windows not otherwise usually on the screen.

 

[Lew]

Ah ha!  Windows -> Debugging -> Threads

It's not open by default.  I still have figured out how to use it to do
what you want, but it's there, and it will take me to a source file.
(In the Java API, for the one I checked.)

The window that shows the suspended threads does come up automatically
in NB when you suspend the program under debug.

 

[Mark Space]

Because my answer was about NetBeans. It was ludicrous to take an
answer about NetBeans and say that it must apply to something else.
My answer was about NetBeans. I was talking about NetBeans (6.5).

Ah ha! NB 6.5 is still in beta. I assumed 6.1, which is the current
release version.

So, again, here's the information I was trying to give you - NetBeans
has the feature that when you suspend a program in the debugger, there
is a window with all the extant threads visible in the debugger view.

Not by default, although once you open the window in the debugger, it
will show the Threads window again next time it is started, at least on
the same project.

If you (double-)click on one of the threads in that window, actually
on one of the expanded items within that thread, it will take you to
the corresponding line of source in the editor window, if available.

Not in 6.1. The work around I posted previously does a decent job. I'm
looking forward to 6.5's new features.

Note that the debugger view in NetBeans is not a separate
"perspective" but merely the view you have when you invoke the
debugger. Invoking the debugger automatically brings up certain
windows not otherwise usually on the screen.

Only Local Variables, Call Stack, and Breakpoints are open by default on
the current stable release of NetBeans. The other 7 odd debugger
windows have to be opened manually. Although as I mentioned it seems to
remember the windows you had open last time you invoked the debugger and
will open those for you again.


Overall, a little snarkiness by both of you. Lew, you should have
mentioned you were using a beta build, because it *is* different than
the stable version. Nelson, you should have actually looked for a
debugger windows named "Threads" rather than posting the quip you did.
That's how I found it, by looking.

 

[Mark Space]

I have been using NB since the 3.x series, and for quite a while now
it's been opening that debugger window for me every time I suspend the
debugged app, since forever it seems. Certainly since 6.1 or earlier.

I'm going to guess here, but when I upgrade with NetBeans it asks me if
I want to import settings from my previous installation to the new one.
It's possible you opened up that Threads window sometime in the mists
of time and have been importing its state ever since.

If you do test this, try a virgin install or don't import the settings.
I'm pretty sure I've always had just the three debugging windows open
from the start, although I suppose it's also possible that I may have
closed a couple of debugging windows early on as too confusing and
forgot it had ever been open.

 

[Nelson Ashton]

Because my answer was about NetBeans.

It looked like a confused or mistaken answer, because what you
described fits Eclipse to a T, but does not fit NetBeans well at all.

So, again, here's the information I was trying to give you - NetBeans
has the feature that when you suspend a program in the debugger, there
is a window with all the extant threads visible in the debugger view.

I suspended a program in the NetBeans debugger yesterday, and no such
window appeared.

I distinctly remember that such things DID happen with ECLIPSE.

Somebody is confused here, as we are apparently not talking about the
same software using the same names.

If you (double-)click on one of the threads in that window, actually
on one of the expanded items within that thread, it will take you to
the corresponding line of source in the editor window, if available.

The only threads window I recall seeing shows thread state, but when
threads are double-clicked, just shows pie charts for the time the
thread has spent idle, active, and so forth, and does not show very
much else. I definitely poked around it a bit to see if something
would provoke the appearance of a stack trace, or navigation in a code
window, without any such results. I also suspended a program in the
debugger and nothing in particular happened other than that the
program suspended.

I'm becoming convinced that the software you are referring to as
"NetBeans" is not the software I am referring to as "NetBeans".

And since the latter is what I got by downloading NetBeans from its
official source ...

Note that the debugger view in NetBeans is not a separate
"perspective" but merely the view you have when you invoke the
debugger.  Invoking the debugger automatically brings up certain
windows not otherwise usually on the screen.

That much is true, but I don't recall a threads window being among
these, or any of them being very useful if you suspend arbitrarily
rather than the program hitting a breakpoint.

 

[Nelson Ashton]

 Nelson, you should have actually looked for a debugger windows named
"Threads" rather than posting the quip you did.

I didn't post a "quip", I posted a simple observation. And I did look
for anything to do with threads, in the open windows and in the debug
menu as well as by putting "thread dump" into the help search.

Just because somebody didn't find something doesn't mean they didn't
look. I looked in the view and debug menus, since opening a new view
might be in the former and debug-related actions might be in the
latter. I didn't look in the window menu, but that's because the
traditional use of a window menu is to list the windows already open
and provide a bunch of useless options like tile, cascade, and the
like that tend to mess up your nicely arranged display, plus a list of
open windows that can be useful to navigate to a particular one if
there's tons of them open and covering one another up.

Apparently, the kinds of options usually placed in the view menu are
divided between the view and window menus in NetBeans.

I'll look there for NetBeans view options I don't find in view in the
future.

Problem solved, I hope.