This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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.
author and iconoclast
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?
Joined: Oct 30, 2001
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.
Joined: Oct 30, 2001
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 ]