Java Help

[Mahesh_20]

Hello,

I am looking for some kind of help wrt to Java.

I have learnt that “kill –SIGQUIT pid” produces the thread dump for Java process. And to get thread dump of interactive Java process, we need to press “control+\”

While the control+\ combination works fine, the kill –SIGQUIT does not seem to function; I mean; it does not produce the thread dump.

Is there any special requirement to produce the thread dump?

Also is there any way to make out determine the state of the threads? Once we have determined the thread status, how do we know that threads are waiting on something else; what state it could be in?

Also is there any way to find out whether the JVM (java virtual machine) has hanged?

Is there any article/write up to learn this?

Thanks and Best Regards.

Mahesh R. Gune

[Rick Retterer]

Mahesh,
We need to know what version of Java you are using before we can fully answer your question.

However, anytime that I need to dump the threads of my java application, a simple:

# kill -3

fills the bill. There should be nothing else that you need to do.

In regards to looking into a running java application to find out the status of your threads and such, you probably would want to use the ladebug debugger to connect to the running process and output the information that you need.

Make sure that you have a Ladebug version of 4.0-63 or higher.

You can download Ladebug from:

http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,5258,00.html

Locate the java_g executable for the version you are using.

For SDK v 1.1.7: /usr/bin/alpha/native_threads/java_g
For SDK v 1.1.8: /usr/opt/java118/bin/alpha/native_threads/java_g
For SDK v 1.2.2: /usr/opt/java122/bin/alpha/native_threads/java_g
For SDK v 1.3.0: /usr/opt/java130/bin/alpha/native_threads/java_g
For SDK v 1.3.1: /usr/opt/java131/bin/alpha/native_threads/java_g
For SDK v 1.4.0: /usr/opt/java140/bin/java_g
For SDK v 1.4.1: /usr/opt/java141/bin/java_g
For SDK v 1.4.2: /usr/opt/java142/bin/java_g

1) Modify the application to use "java_g" instead of "java".
This will provide us with symbols that we can use to look into java code.
/usr/opt/java142/bin/java_g

2) You will need to have "debug" versions of any shared "C" libraries,
(like Oracle's JDBC C Shared Libs.),or make a copy of the existing
C share libraries and modify the name so that it fits the format of:

lib_g.so

Example:
"libocijdbc8.so" would need to be copied to "libocijdbc8_g.so"

This will satisfy the debugger's requirements for "debuggable" shared
libraries, for your Java Applications.

3) Once you have the application running under "java_g", then when the application
hangs again, use the ladebug debugger to "attach" to the process and then follow
the instructions below.

# ps -ef | grep java_g {obtain pid_of hung_java_process}

# ladebug

(Ladebug) attach /usr/opt/java142/bin/java_g

{Execute the commands in section C. listed below.}


C.) Use the record command for convenience in saving the results to a file.
========================================================================

(Ladebug) record io core_results.txt

Examine the stack trace.

(Ladebug) where

Dump the active function's local variables and parameters.

(Ladebug) dump

Execute the following threads commands to display detailed information about the threads:

(ladebug) where thread * # dumps stack trace of all threads
(ladebug) pthread "system" # system info
(ladebug) pthread "versions" # DECthreads version
(ladebug) pthread "vp" # Brief listing of VPs
(ladebug) pthread "thread -1a" # Brief listing of threads
(ladebug) pthread "mutex -faql" # Full listing of all locked mutexes
(ladebug) pthread "cond -faqw" # Full listing of all CV's with waiters
(ladebug) pthread "rwlocks -faqr # Full listing of all read-locks
(ladebug) pthread "rwlocks -faqw # Full listing of all write-locks
(ladebug) pthread "show -tuvk" # Timeslice, Upcall, VP (on old versions), and kernel information
(ladebug) pthread "vp -f" # Full info on all VPs
(ladebug) pthread "thread -fa" # Full info on all threads
(ladebug) pthread "stacks -fs" # Display each threads' stacks beginning and end points.
(ladebug) pthread "mutex -faq" # Full info on all mutexes
(ladebug) pthread "cond -faq" # Full info on all CV's
(ladebug) pthread "rwlocks -faq # Full listing of all write-locks
(ladebug) pthread "vm -cf" # DECthreads internal memory manager
(ladebug) pthread "keys" # List of per-thread context keys
(ladebug) pthread "mutex -h" # History for mutexes, if available (typically not)
(ladebug) pthread "cond -h" # History for condition variables, if available

Finally, simply review the ouput file that was created.

This will give you some insight as to what is happening with your java application.

[patnaboy]

hello guurs,
i am having the same situation but on hp11.11i

the set up is that, one java process creates another process and on freeze condition i am able to get the thread dump from the parent but not the child. the application processes heavy network communication. java 1.4.2_04 is used.
okei this is sketchy description of the problem. i can come back with more information if something specific is requested.

please throw some light on this one
/Abhi