I spent the last 4 hours trying to set up Eclipse TPTP memory
profiling on a Tomcat instance that must be run remotely (i.e. not in
Eclipse). This should be possible according to the TPTP and Agent
Controller docs.
I installed the TPTP components (4.6.0) into my Eclipse (Galileo)
workbench, along with the Agent Controller according to the
instructions on the website. To enable the agent, I added the
following options to the command line that starts the Tomcat instance:
-agentlib:JPIBootLoader=JPIAgent:server=enabled;HeapProf:allocsites=true
and added the following directories to the front of the PATH:
D:\dev\tools\ac\plugins\org.eclipse.tptp.javaprofiler
D:\dev\tools\ac\bin
When attempting to start Tomcat I consistently got the following error
message:
ERROR: JDWP unable to get necessary JVMTI capabilities. ["debugInit.c",L279]
I did a lot of Googling but found nothing relevant; I tried
reinstalling TPTP and various versions of the Agent Controller.
In the end the problem turned out to be that I was starting Tomcat
with the "jpda" option, which catalina.bat translates into
-Xdebug -Xrunjdwp:transport=.....
Removing the "jpda" command argument caused JVMTI to start working.
SO, the question is: I found nothing during any of my searches to
indicate that a JVMTI agent is incompatible with debugging. Can
someone explain what is going on and why JVMTI + JDWP is not a valid
setup?
None of the answers so far are correct and this is the first hit that comes up on Google if you query the error mentioned, so I feel some clarification is needed.
JVMTI and JDWP do work together, in fact they generally must be used together. You will get ERROR: JDWP unable to get necessary JVMTI capabilities if -Xrunjdwp (and/or possibly -agentlib:jdwp) is specified more than once on the command line. To fix it, make sure you only have one of -Xrunjdwp or -agentlib:jdwp in your command line.
For more details, read on...
JVMTI (Java Virtual Machine Tool Interface) is the successor to JVMDI (Java Virtual Machine Debug Interface) and JVMPI (Java Virtual Machine Profiling Interface). It incorporates the functionality of both JVMDI and JVMPI, both of which were deprecated in Java 5 and removed in Java 6. It is the API that exposes the internals of the JVM for the purposes of debugging and profiling.
JDWP (Java Debug Wire Protocol) is a protocol that describes a simple mechanism for transmitting commands and responses. As far as I know, it is the only way for a debugger sitting outside the JVM to communicate with it and to interface with the JVMTI.
JDI (Java Debugger Interface) is a client-side (debugger-side) API which exposes some of the features of JVMTI while making use of JDWP more or less transparently.
The bug mentioned in Bob Dobbs's answer concerns the misleading error message, and the fact that the JVM will try to load JDWP once for every time it is specified on the command line. It doesn't state anywhere that JDWP and JVMTI cannot be used together.
More info here: https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzaha/jpdebuga.htm
I ran into the same problem as you, but I came up with a JVM bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6354345) that cast some light on the issue. It basically comes down to the Java agent library not ever being intended to be loaded twice into the same VM. Sucks, but seems like it's basic limitation of the agent system that you can't do both at the same time.
For me it was the same issue as Code Bling post, they were duplicate -Xrunjdwp didn't realize there were a second -Xrunjdwp as it was hidden in the variable %JAVA_OPTIONS%, check your Application Server start script.
Related
Trying to run a JMH benchmark on Windows using WinPerfAsmProfiler gives the following error:
ERROR: No address lines detected in assembly capture, make sure your JDK is PrintAssembly-enabled:
https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly
The problem, as the link suggests, is that you must install a disassembler plugin. There are several implementations. However, for reasons of self-censorship and copyright nazism, Windows binaries of most implementations are hard to come by. Additional info can be found in this SO question (in which I've updated the suggested build steps and won't repeat them here).
The other issue you'll hit is that you must run the profiling session as an administrator.
Additional information about the system properties which configure perfasm, can only be found in the source code of AbstractPerfAsmProfiler and WinPerfAsmProfiler (at least, as of version 1.9.2).
A possibly useful tip: You can increase xperf's sampling frequency from 1KHz to 8KHz (and have more precise timing information) by running xperf-setprofint 1221 cached in any Administrator command prompt.
I am profiling a java application using jvisualvm. The CPU profile from jvisualvm has narrowed down the slow part of the code to one particular method. It doesn't say which part of the method is slow though.
To get more information I tried debugging through Eclipse using Java Monitor (available through Eclipse Marketplace). Java Monitor will attach to the application but it won't display CPU statistics. I don't know why. I have modified the JVM options using:
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y
Then I create a profile in Eclipse using:
Remote Java Application > myapplication
Here I select the source code for the project I am profiling. I start the application and it waits for the debugger to attach:
Listening for transport dt_socket at address: 8000
I right click the PID under local host and click 'Start Monitoring'
Then in Eclipse I press F11 to kick off the application. It starts running, but under 'Properties' I get everything except CPU. Any ideas greatly appreciated..
I don't know any Java profiler which can tell you which part of a method eats most of the time. If you can't tell by looking at the method, then your method is probably too big to understand anyway. Try to refactor it into several methods.
If you have lots of local variables, use a worker object and turn local variables into fields of the worker. That way, you can avoid writing methods with a dozen parameters and still cut a overly complex method to size.
As for why Java Monitor doesn't do what you want: You need to tell it which packages to monitor and which profiling method to use. See the documentation for details.
I am constructing a Command Prompt Process in my Delphi application which is able to interact with the JDB to compile, run and debug a Java application. Cmd input/output/errors are handled through pipelining from the cmd to/from my Delphi application UI.
I want the output of the java program when using 'System.out' / 'System.err' to be directed to a component of my Delphi Application and I want input from my delphi application to be sent to 'System.in' allowing me to form a console in my Delphi UI similar to the console in the Eclipse IDE.
A few thoughts on approaches;
An obscure flag (I haven't found) in the Java compiler allowing me to redirect
Using 'System.setOut'/'System.setErr'/'System.setIn' along with a main method in a class which performs this initialization before pointing to the normal main method to run the users code.
NB - I have tried searching through the Eclipse sourcecode to see how they did it but as it is written in Java, I suspect they wouldn't face cross language issues I would face.
I have found a solution to my problem. You need two command prompt processes, each constructed with a Read, Write and Error pipe in Delphi.
One of them runs the Java application and is set to wait for a debugger to be attached before executing and the other is for debugging and is attached to the waiting Java application.
This is for the main application; all application console input/output/errors will be handled through this process.
java -agentlib:jdwp=transport=dt_shmem,address=DelphiExecutingAppAddress,server=y,suspend=y MyClassFile.java
This is for the debugger; all jdb console input/output/errors will be handled through this process (break points, resuming, getting object details).
jdb -attach DelphiExecutingAppAddress
N.B. Perhaps this is what David was referring to? It looks like it was my mistake when reading the jdb documentation in not finding this on the first work-through. Perhaps this thread may help others.
This is on Ubuntu 12.04/ Java 7, 64bit
Working on project to create java bindings for WebkitGtk Version 2. My primary interest in WebkitGTK is DOM access and manipulation as against just displaying web pages. For V2, WebkitGtk team changed architecture which allows DOM access via extensions. Extensions are loaded by WebKitWebProcess which is a separate process fired when webkit is started.
I got most of it under control. My extension is getting loaded and JVM is started and my java classes are getting loaded and mostly working as expected. Right now my debugging technique is basically println statements and/or log statements.
Wondering if I can attach a java debugger so that I can debug java code more easily. If I run jps command, PID of WebKitWebProcess does show up. So someone is aware that this process has JVM. Preferred debugger will be eclipse.
Basically it boils down to how to attach java debugger where VM is stared using JNI_CreateJavaVM and process is already running.
Turned out to be very simple. When you create VM, just pass the debugger option as follows. Connect debugger to port 9836 and you in the debugger.
JavaVMOption options[3];
options[0].optionString = <your classpath>;
options[1].optionString = "-Xdebug";
options[2].optionString = "-agentlib:jdwp=transport=dt_socket,server=y,address=9836,suspend=n";
I wanted to get ideas from the SO community about this issue.
Here is the problem:
We have a user on the other side of the world launching our app through WebStart. The user, however, is complaining that her whole application freezes up and becomes unresponsive. Usually, the client is doing a lot of database queries to a distributed database.
Questions:
If we ask her to do a CTRL-Break on her application, where would the JVM write the stack trace to?
Would it be enough just to use JConsole?
Would implementing JMX beans on the client be overkill? Would it actually help in troubleshooting issues in production?
Right now the users are running on JRE 1.5.0-b08, but we do plan on migrating to JRE 6 in a couple of months.
What do you think?
José, you can get a lot of information from the JVM in a number of ways.
The best might be to enable debugging in the remote JVM. You can set them using the j2se element in the descriptor XML, as shown here. Since you can set -Xdebug you have a good start; I've never tried to do remote debugging on a web start app, so it may be a little bit of an issue setting up the remote part.
You could also set some things up yourself by adding a separate thread to talk to you remotely and send debugging messages.
You could use a native java or log4j remote logger.
If it's hanging the way you describe, though, the odds are very high that what's happening is a network hangup of some sort. Can you put some tracing/debugging onto your end of the conversation?
Instead of these debugging suggestions, why don't you install an exception handler for your threads? See java.lang.Thread.
void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)
Here's the relevant javadoc:
http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)
If you install that in your code, and once inside Swing's EDT, then just write some java code to e-mail it to yourself, save it on a server, show it to the user, etc.
You need to have the Java Console displayed (run javaws from the command line, and select this from the Preferences dialog), then hit "v"