aspose file tools*
The moose likes Threads and Synchronization and the fly likes List the running threads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "List the running threads" Watch "List the running threads" New topic
Author

List the running threads

Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
I have an application which is not shutting down properly. I need to find out what is going wrong. I would like to be able to list the threads that are running. Unfortunately, I don't seem to have the tools to do so.

The application uses Java 1.4.1. It runs from our custom Java launcher, and does not have a console window (so I can't press CTRL-BREAK and look at the results). In the problematic case, it is actually running in Windows system tray.

Attachment of the debugger is not allowed, I think. The "-Xdebug" and "-Xrunjdwp" arguments are only included in the debug build and - you guessed it - the problem doesn't happen then.

I tried the instrumentation "jvminst" for Java 1.4. It works, but only really seems to give memory and GC information, which is not relevant to this problem.

Any ideas how I might find the running threads?


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

Can you add code to the application (or the custom launcher) or not?


[Jess in Action][AskingGoodQuestions]
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Yes I can, but I was hoping to avoid doing so. I wanted to investigate this problem with the existing installation. It is an intermittent problem, which tends to go away for long periods and I am afraid it may go away again before I get any diagnostic info.

I'd really like to be able just to attach some tool to the JVM, like you can in later versions of Java.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

Under UNIX, pressing Control-\ sends a specific signal (QUIT, or 3) to the process in the terminal. When a UNIX JVM gets that signal, it emits the stack trace. You don't have to use Control-\, though -- you can send the signal any way you want, including witht he command-line "kill" program. I do this all the time to force background processes to stackdump.

I wonder if on Windows it works the same way. ANSI C includes the signal() function, which on UNIX will send the same kind of signals. Perhaps Control-Break sends QUIT/3 to a process on a terminal, in which case maybe ANSI signal() can be used to force a Windows JVM to stackdump? I just Googled a little and it doesn't look good.

I found one document describing a situation similar to yours where they suggest using java.exe rather than javaw.exe when debugging Java running as a service; then you can get a terminal to type Cntrl-Break into. Sounds like you can't do that either, though?
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Thanks. The chances of debugging my issue without changing code don't look good, so I'll go ahead and add logging etc. Hopefully, this won't make the issue go hide!

FWIW I'm not running as a service (though the app can run that way), but I am not using java.exe or javaw.exe, but instead my own Java launcher.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
The following tool stacktrace can get a full stack dump for a Java 1.4 JVM, even under the difficult conditions of my application.

Recommended for any other Java 1.4 users. For later Java, Sun's own tools are probably preferred.
[ September 22, 2006: Message edited by: Peter Chase ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: List the running threads