JProfiler Assertion failed - jprofiler

I am trying to launch JProfiler 6 in remote mode and get the following error:
JProfiler> Protocol version 28
JProfiler> Using JVMTI
JProfiler> JVMTI version 1.1 detected.
JProfiler> 64-bit library
JProfiler> Listening on port: 8849.
JProfiler> Instrumenting native methods.
JProfiler> Can retransform classes.
JProfiler> Native library initialized
JProfiler> VM initialized
JProfiler> Waiting for a connection from the JProfiler GUI ...
JProfiler> Using dynamic instrumentation
JProfiler> Time measurement: elapsed time
JProfiler> CPU profiling enabled
Assertion failed: (agentClassLocal), function initReferences, file /Users/hannes/buildsys/jprofiler/build/src/c/agent/shared/LiveProfilingSession.cpp, line 95.
Can someone please explain what they are from and how to fix them?
Thanks!

You're missing the reference to agent.jar:
-Xbootclasspath/p:/opt/jprofiler/bin/agent.jar

Related

JProfiler is stuck at VM initialized Phase

I am trying to connect to remote JVM and passing following JVM flag:
-agentpath:/home/vishalgarg/jprofiler11.1.4/bin/linux-x64/libjprofilerti.so=port=8849,nowait
However, the process is getting stuck at VM initialized phase. Can anyone help me in understanding the root cause?
JProfiler> Protocol version 63
JProfiler> Java 8 detected.
JProfiler> Don't wait for frontend to connect.
JProfiler> 64-bit library
JProfiler> Starting up without initial configuration.
JProfiler> Listening on port: 8849.
JProfiler> Enabling native methods instrumentation.
JProfiler> Can retransform classes.
JProfiler> Can retransform any class.
JProfiler> Native library initialized
JProfiler> VM initialized

A fatal error has been detected by the Java Runtime Environment: SIGBUS while installing ZAP proxy in parrot home OS

I was trying to install the ZAP proxy in my parrot home OS, but I'm unable to install it and the error that I'm receiving in the terminal is as follows:
(A fatal error has been detected by the Java Runtime Environment:
SIGBUS (0x7) at pc=0x00007f904544b12f, pid=6446, tid=6447JRE version: OpenJDK Runtime
Environment (11.0.5+10) (build 11.0.5+10-post-Debian-2)
Java VM: OpenJDK 64-Bit Server VM (11.0.5+10-post-Debian-2, mixed mode, sharing, tiered,
compressed oops, g1 gc, linux-amd64)
Problematic frame:
V [libjvm.so+0xcce12f]
No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
If you would like to submit a bug report, please visit:
(https://bugs.debian.org/openjdk-11)
Aborted
This error message...
(A fatal error has been detected by the Java Runtime Environment:
SIGBUS (0x7) at pc=0x00007f904544b12f, pid=6446, tid=6447JRE version: OpenJDK Runtime
Environment (11.0.5+10) (build 11.0.5+10-post-Debian-2)
Java VM: OpenJDK 64-Bit Server VM (11.0.5+10-post-Debian-2, mixed mode, sharing, tiered,
compressed oops, g1 gc, linux-amd64)
Problematic frame:
V [libjvm.so+0xcce12f]
...implies that the V frame was the Problematic frame which crashed which resulted in libjvm.so file.
The crash you observed is possibly not a zap or java issue but a debian issue.
Deep Dive
However as per the documentation in What versions of Java are supported? page, ZAP should be able to run with all/newer Java versions, but might require a minimum for certain ZAP versions:
ZAP 2.7.0 and later requires a minimum of Java 1.8
ZAP 2.0.0 and later requires a minimum of Java 1.7
Previous versions of ZAP also support Java 1.6, the last of those being 1.4.1
Additionally, as per the documentation in Download ZAP page:
The Windows and Linux versions require Java 8 or higher to run.
The macOS version includes Java 8 - you can use the Linux or Cross Platform versions if you do not want to download this.
Finally, as per the documentation in Release 2.9.0 page:
This is a bug fix and enhancement release, which requires a minimum of Java 8. Note that a minimum of Java 11 is recommended, especially for high DPI displays.
References
You can find a couple of relevant discussions in:
Jvm crash :fatal error has been detected by the Java Runtime Environment
“A fatal error has been detected by the Java Runtime Environment” when running java project on another computer
A fatal error has been detected by the Java Runtime Environment (SIGBUS (0x7))
JVM crashes with problematic frame [libjvm.so+0x7f582e] PerfLongVariant::sample()+0x1e

JProfiler GUI on local windows machine can't connect to remote Linux server machine

1) I ran my server program on a linux machine, remotely.
JProfiler> Protocol version 41
JProfiler> Using JVMTI
JProfiler> JVMTI version 1.1 detected.
JProfiler> 64-bit library
JProfiler> Listening on port: 8849.
JProfiler> Instrumenting native methods.
JProfiler> Can retransform classes.
JProfiler> Can retransform any class.
JProfiler> Native library initialized
JProfiler> VM initialized
JProfiler> Waiting for a connection from the JProfiler GUI ...
2) I then try to connect my profiler GUI from my local windows machine. I got the config.xml from the server generated by JProfiler and imported it via the GUI. When I try to connect, I get a "Connection status" in progress forever.
i am able to telnet to the Linux machine to the specific port, 8849.
Interestingly, when i kill the server on the Linux machine, the "Connection status" dialog box on my GUI is also killed. And it shows this message.
"Either an old version of the native library is used or another application is listening on port 8849. Please check your PATH environment variable and your port configuration".
I've found out my issue. My client side has version 8.07 while my server side has version 8.10. After I upgrade my client side, everything works.

JProfiler GUI on 32 bit machine connecting to 64bit server

I am profiling a java process which is running on 64 bit JVM on a linux box, I cant launch a GUI on that linux box.
When i connect from my 32 bit windows box i get error
JProfiler> ERROR: another application or a different
JProfiler> version of JProfiler tried to connect.
Is it that i need a 64 bit machine to connect to the remote 64 bit machine and get the profiling details?
You have to use the same version of JProfiler for the profiling agent (on the remote Linux box) and the JProfiler GUI (on your local Windows machine).
The "bitness" of the profiling agent does not matter.

How to unintegrate jprofile with netbeans

I installed jprofile to investigate a memory leak and also clicked the integrate IDE with netbeans 6.9.1. Runing my Web application worked well when clicking the Profile Project, However, when I want to debug again the project the jprofile is still being run when I just want to debug [i.e. Clicking the debug button instead of Profile]. This causes the debugging to fail all the time.
Glassfish Server Output Console.
JProfiler> Protocol version 33
JProfiler> Using JVMTI
JProfiler> JVMTI version 1.1 detected.
JProfiler> 32-bit library
JProfiler> Listening on port: 33200.
JProfiler> Instrumenting native methods.
JProfiler> Can retransform classes.
JProfiler> Can retransform any class.
JProfiler> Native library initialized
JProfiler> VM initialized
JProfiler> Waiting for a connection from the JProfiler GUI ...
I did not said to profile but still this log shows in the console. I tried to look at any uninstall or unintegrate option within the jprofile and there is non. But the jprofile is also not registered as a plugin when looking at the Tools > Plugins menu. Is there a way to unintegrate jprofile?
Note: I already grepped the whole "C:\Program Files\Netbeans 6.9.1\" folder and already removed the xml config of jprofile plus the jar inside the "modules\" folder. But after restarting netbeans and clicking debug button. It still shows the JProfiler prompt.
1. \NetBeans 6.9.1\ide\config\Modules\com-jprofiler-integrations-netbeans.xml
2. \NetBeans 6.9.1\ide\update\backup\netbeans\config\Modules\com-jprofiler-integrations-netbeans.xml
Debugging should not append the VM parameter for profiling (-agentpath) to the java command, even if the JProfiler integration is installed, so this sounds kind of strange.
Look into the %USERPROFILE%.netbeans\6.9\modules directory and delete com-jprofiler-integrations-netbeans.jar. If that file does not exist either, the -agentpath parameter is added in a different way, maybe explicitly in your debug configuration.