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.
In http://qa.netbeans.org/bugzilla/generating-thread-dumps.html I read about generating a thread dump for the IDE. But I would like to generate a thread-dump for a java application started from the IDE (but not in debugger). In IntelliJ there is a button for this right next to the corresponding console output window.
Not possible to initiate this from Java code. Need to use some platform-specific tricks. No plans to implement anytime soon.
One of the trick is 'jstack' utility that is part of JDK1.5. Unfortunately it does not work well on my linux box (fedora core2)
In Java 5 we have public static Map<Thread,StackTraceElement[]> getAllStackTraces() in java.lang.Thread. This would do the Job without any platform-specific tricks.
The method is not too helpfull here as the biggest problem would be how to trigger execution of some code in running JVM process.
Best handled by JMX integration, I guess.
1) In JMX Module, in order to attach to the launched JVM with JConsole, we are adding a virtual PID (in fact a simple key to the jvm command line) to discover the current launched JVM. We are also adding a specific property (com.sun.management.jmxremote) to enable JMX access. In Mustang, it is no more needed to add this property. ==> We could have a new property in Project properties to enable Management when launching the JVM. Doing so we would have the door opened to ask for stack traces (AND MUCH MORE). 2) Using some private API located in tools.jar (that should become public in Mustang), we are searching for the key in the set of local running JVM. WARNING : This doesn't work on FAT File System for security reasons. On FAT, we are not making use of this API, we are connecting in the classical way (Connect to well known RMI port). I think that this limitation is still true with Mustang. ==> This means that we could have a Project property saying on which RMI port the JVM should be listening. Doing so we would have a portable way to enable the management. 3) Knowing how to connect to the JVM, we could easily, from netbeans, call for stack traces and display them in output console (Simulating a Ctrl\ typed in the Input Textfield).