My tomcat (version: 5.5.25) runs an application which I try to profile with VisualVM (ver: 1.3.2).
Everything looks nice but not all classes and methods are shown in visualVM. They ones that are missing run in thread [main]. I know this because this is the thread's name I receive if I a breakpoint has been hit. Classes which run outside main e.g. [worker1] , [worker2], ... are shown correctly.
Any idea what the reasons might be? Or what I could try?
Since the application I run (it is called Assentis Docbase) is closed-source they might have customized the default tomcat configuration. But they allowed me to extend the framework with my own classes and that are the ones I want to profile.
VisualVM I run with the default configuration as downloaded.
You probably need to customize profiling root methods. See Profiling With VisualVM, Part 1 and Profiling With VisualVM, Part 2. You can also use 'Sampler' tab to get high-level picture of what is your Tomcat doing.
Here are a couple of reasons why you may not be able to see the "main" thread:
The thread could have exited.
The thread could have changed its name by calling Thread.setName().
If you want to figure out the real reason, you will probably need to look at the Tomcat source code.
This page tells you where the settings are. Google is your friend.
The reason why VisualVM did not show my method calls in thread [main] is that VisualVM allows only to profile up to 32 threads simoultanously. It is NOT possible to allow more threads to be watched. This has been documented in Profiling With VisualVM, Part 2, section "Comparison With The NetBeans Profiler" they say:
"Profiled threads limit is always 32."
:-(
You've probably badly configured "Start profiling from classes" in the plugin config.
Say you've configured org.acme.competition.* (A) for profiling:
but you've accidentally profiled the class org.acme.reference.ReferenceImpl (B) using a command lie this:
$ cat source.txt | java -Xverify:none \
-agentpath:/usr/share/visualvm/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so=/usr/share/visualvm/profiler/lib,5140 \
-cp bin/ org.acme.reference.ReferenceImpl
then this would be the wrong result:
When configuring VisualVM's Startup plugin config "Start profiling from classes" with org.acme.reference.* instead, the result is correct:
See the Startup profiler guide too.
Related
In Java profiling, it seems like all (free) roads nowadays lead to the VisualVM profiler included with JDK6. It looks like a fine program, and everyone touts how you can "attach it to a running process" as a major feature. The problem is, that seems to be the only way to use it on a local process. I want to be able to start my program in the profiler, and track its entire execution.
I have tried using the -Xrunjdwp option described in how to profile application startup with visualvm, but between the two transport methods (shared memory and server), neither is useful for me. VisualVM doesn't seem to have any integration with the former, and VisualVM refuses to connect to localhost or 127.0.0.1, so the latter is no good either. I also tried inserting a simple read of System.in into my program to insert a pause in execution, but in that case VisualVM blocks until the read completes, and doesn't allow you to start profiling until after execution is under way. I have also tried looking into the Eclipse plugin but the website is full of dead links and the launcher just crashes with a NullPointerException when I try to use it (this may no longer be accurate).
Coming from C, this doesn't seem like a particularly difficult task to me. Am I just missing something or is this really an impossible request? I'm open to any kinds of suggestions, including using a different (also free) profiler, and I'm not averse to the command line.
Consider using HPROF and opening the data file with a tool like HPjmeter - or just reading the resulting text file in your favorite editor.
Command used: javac -J-agentlib:hprof=heap=sites Hello.java
SITES BEGIN (ordered by live bytes) Fri Oct 22 11:52:24 2004
percent live alloc'ed stack class rank self accum bytes objs bytes objs trace name
1 44.73% 44.73% 1161280 14516 1161280 14516 302032 java.util.zip.ZipEntry
2 8.95% 53.67% 232256 14516 232256 14516 302033 com.sun.tools.javac.util.List
3 5.06% 58.74% 131504 2 131504 2 301029 com.sun.tools.javac.util.Name[]
4 5.05% 63.79% 131088 1 131088 1 301030 byte[]
5 5.05% 68.84% 131072 1 131072 1 301710 byte[]
HPROF is capable of presenting CPU usage, heap allocation statistics,
and monitor contention profiles. In addition, it can also report
complete heap dumps and states of all the monitors and threads in the
Java virtual machine.
The best way to solve this problem without modifying your application, is to not use VisualVM at all. As far as other free options are concerned, you could use either Eclipse TPTP or the Netbeans profiler, or whatever comes with your IDE.
If you can modify your application, to suspend it's state while you setup the profiler in VisualVM, it is quite possible to do so, using the VisualVM Eclipse plugin. I'm not sure why you are getting the NullPointerException, since it appears to work on my workstation. You'll need to configure the plugin by providing the path to the jvisualvm binary and the path of the JDK; this is done by visiting the VisualVM configuration dialog at Windows -> Preferences -> Run/Debug - > Launching -> VisualVM Configuration (as shown in the below screenshot).
You'll also need to configure your application to start with the VisualVM launcher, instead of the default JDT launcher.
All application launches from Eclipse, will now result in VisualVM tracking the new local JVM automatically, provided that VisualVM is already running. If you do not have VisualVM running, then the plugin will launch VisualVM, but it will also continue running the application.
Inferring from the previous sentence, it is evident that having the application halt in the main() method before performing any processing is quite useful. But, that is not the main reason for suspending the application. Apparently, VisualVM or its Eclipse plugin does not allow for automatically starting the CPU or memory profilers. This would mean that these profilers would have to be started manually, thereby necessitating the need to suspend the application.
Additionally, it is worth noting that adding the flags: -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y to the JVM startup will not help you in the case of VisualVM, to suspend the application and setup up the profilers. The flags are meant to help you in the case of profilers that can actually connect to the open port of the JVM, using the JDWP protocol. VisualVM does not use this protocol and therefore you would have to connect to the application using JDB or a remote debugger; but that would not resolve the problem associated with profiler configuration, as VisualVM (at least as of Java 6 update 26) does not allow you to configure the profilers on a suspended process as it simply does not display the Profiler tab.
This is now possible with the startup profiler plugin to VisualVM.
The advice with -Xrunjdwp is incorrect. It just enables debugger and with suspend=y it waits for debugger to attach. Since VisualVM is not debugger, it does not help you. However inserting System.in or Thread.sleep() will pause the startup and allows VisualVM to attach to your application. Be sure to read Profiling with VisualVM 1 and Profiling with VisualVM 2 to better understand profiler settings. Note also that instead of profiling, you can use 'Sampler' tab in VisualVM, which is more suitable for profiling entire java program execution. As other mentioned you can also use NetBeans Profiler, which directly support profiling of the application startup.
I am trying to debug a program running on a remote solaris machine.
I wanted to know path taken by the program during the execution just like stake trace
like
Class A.method1 called method2 in class B
Class B.method2 called method3 in class C
..
...
Control returned from method2 in class B to
method1 in Class A etc
We cannot run the program from eclipse since the environment cannot be reproduced since it is a large enterprise level system having many upstream and downstream systems.
I suspect somewhere in the program there is an exception being thrown and that is not handled properly like a empty catch block/not logging or rethrowing the exception.
What is the best way to debug such programs. Please help me with your solutions.
You can use Eclipse to debug remote applications, all you need to do is add a few startup parameters: http://eclipse.dzone.com/articles/how-debug-remote-java-applicat
You can debug remotely with eclipse, see this
If you want to trace the execution of your Java code you can use a tool called InTrace.
InTrace supports outputting the trace from a Java program to disk or over the network to the InTrace UI. This should be ideal for debugging your Java program on a remote solaris machine.
NOTE: InTrace is a free and open source tool which I have written.
Since, your remote machine runs under Solaris you could use DTrace to dynamically add probes to your running JVMs and the complete system.
You could remote debug, which Eclipse supports, but may not be permitted by the system admin. The only other thing I can think of is lots and lots of logging
in such cases I have used Btrace https://dzone.com/articles/introduction-btrace , it doesn't require you to setup a remote debugger, nor to have the source code of your Java application.
Another way is to run jdb https://docs.oracle.com/javase/7/docs/technotes/tools/windows/jdb.html and attach to the process - but you must enable the process JVM to use jdwp -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n
In general I agree that the JDK is lacking a professional built-in tracing/debugging tool
I've looked through couple of articles here such as:
java stack dump on windows
Thread dump programmatically /JDI (Java Debugger Interface)
But didnt catch the exact answer.
The problem:
There is a Java5 Application on Windows that's runs as a service (so we dont have a console where we are able to use Ctrl+Break for Dumping).
And sometimes Application hangs and we need a thread dump.
We've tried "jstack" but it doesnt work in our env (we found out that its Java6 only compatible).
So we made a C++ app that calls thread dump via .dll call method attaching to the Java app process, and because of this it needs Local Admin rights, that is not so good.
So we'd like other options that works without admin rights and works with Java 5 without lots of rework of existing code.
Method with Printing in LOOP thread dumps (Thread.getAllStackTraces()) is not an option because we need to refactor lots of applications in order to make it work.
So that just an util that works from "outside" of applications would be a best option.
Thanks in advance!
One option is to dump all the information using jmap, and then analyzing it using other tool.
jmap -dump:format=b,file=<filename>.hprof <jvm_pid>
I am not sure, buy I think it will work on Java 5.
References:
HPjmeter-like graphical tool to view -agentlib:hprof profiling output
You can attach to the process with JConsole to detect deadlocks and get stack traces of the threads. For more information, see here: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
I have a java process running on a Linux box, but it cannot be started/re-started in debug mode. I read about the jsadebugd command and started the daemon, but I want to connect to it from an IDE(possibly Eclipse) debugger or maybe YourKit or jconsole. How can I do this? The remote JVM is 1.6+.
I assume since you mentioned Yourkit and other tool that what you really want to do is look at object state inside your applications. There are a couple of options, though I don't think it gets you the ability to set break-points like Eclipse or another debugger would (though I'd be intersted in hearing what restricts you from starting the process in debug mode - technical? process?)
have you tried connecting with: VisualVM? I don't believe you need to start in debug mode, and it will give you the ability to navigate the object graph, and inspect objects. You can even use it to take heapdumps and do some ad-hoc analysis through them using OQL queries.
If you're running on JDK6+ - have you tried instrumenting with btrace? Some notes from the sailfin team sounded promising, and like DTrace in Solaris, this seem like it would be useful in a variety of situations.
I am not sure if I understand your restrictions correctly but you can start JVM with debugging server (serving JDWP) enabled. See for example "Sun VM Invocation Options" in http://java.sun.com/j2se/1.4.2/docs/guide/jpda/conninv.html
Then you can connect your Eclipse debugger to running JVM. See "Remote debugging" section here http://www.ibm.com/developerworks/library/os-ecbug/
I'm not sure that this is exposed by Eclipse, but here's how to do it with jdb:
http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/tooldescr.html#gbmog
I'm launching a Weblogic application inside Eclipse via the BEA Weblogic Server v9.2 runtime environment. If this were running straight from the command-line, I'd do a ctrl-BREAK to force a thread dump. Is there a way to do it in Eclipse?
Indeed (thanks VonC to point to the SO thread), Dustin, in a comment to his message, points to jstack.
I have run a little Java application (with GUI) in Eclipse, I can see the related javaw.exe in Windows' process manager and its PID, 7088 (it is even simpler in Unix, of course).
If I type at a command prompt jstack 7088, I have the wanted stack dump per thread.
Cool.
Would be better if we could do that directly from Eclipse, but that's already useful as is.
You can do it when you are in debug mode: go to the debug view in the debug perspective, click on the process you have launched and click on pause, you will get a graphical stack of all your processes.
Note : this also works when using remote debugging, you do not need to launch weblogic from eclipse, you can launch it on its own, open the debugging ports and create a "remote java application debug configuration" for it.
check SendSignal:
http://www.latenighthacking.com/projects/2003/sendSignal/
Eclipse Wiki: How to Report a Deadlock lists all possible options of creating a thread dump in Eclipse. Depending on the concrete situation, one or the other may work better -- my personal favorite on Windows is the Adaptj Stacktrace tool.
StackTrace is another option that you could try. From the features:
Thread dump for Java processes running
as a Windows service (like Tomcat, for
example), started with javaw.exe,
applets running inside any browser or
JVMs embedded inside another process.
StackTrace works on Windows, Linux and
Mac OS X.
if you prefer UI based solution visualvm might be a good choice. (it's advantage is also that it's distributed with JDK)
To take the thread dump in visualvm:
connect to process (remote or local) and
go for Threads (tab) -> Thread Dump (button)
Did you try to launch your eclipse with java.exe instead of javaw.exe (in your eclipse.ini) ?
That might give you the console you need, as described in this bug and in this message.
Other ideas (in term of java options) could be derived from this other SO question.
You can connect through the JVisualVM and get a thread dump. Just right click on the application node from the Applications tree and select "Thread dump"
On linux at least you can do a ps -ef | grep java to get the PID and then do a kill -3 PID and it will output it to the Eclipse console.