I have a simple Java applet that I'm running from an HTML page on my computer (i.e. file:///C....). It works fine even when I start it in debug mode, which I do with "suspend=y". When I attach the debugger it works great if breakpoints are disabled. It also works fine if I stop at breakpoints and quickly go on to the next one, if any. The problem arrises only when I linger on a breakpoint about 7 to 9 seconds. If I do that the application crashes: The Java console disappears without any messages, the jp2launcher.exe task terminates, and the debugger "disconnects".
I would like to know whether or not other people have this problem debugging Applets with Java 1.8.0_60. If you can take your time about moving on from a breakpoint I'd like to know what you're doing differently. A breakpoint's not much good if you don't have time to look at the state of things.
I've searched Stack Overflow for tags [applet] and [debugging] with any of the words "crash", "stop", and "terminate" but found only one, irrelevant question.
My environment: I'm running 32 bit Java 1.8.0_60 on 64 bit Windows 7. I run my Applet in Internet Explorer or Firefox. I'm using the IntelliJ debugger. I'd try a different version of Java but that's not an option these days, I believe, without removing all recent versions of Java from my computer - a lot of trouble since I'd need to install them all again.
Related
I need to debug a Java applet. For now, just getting a heap dump would be a big help, although running something like JavaSnoop would be even better.
The complication is that the applet is part of a complex website that only works in Internet Explorer. While it's theoretically possible to isolate the applet and run it independently, initial attempts to do this have failed.
I have attempted these instructions. However, the debug settings are not taking effect for the Java VM that is running the applet. Port 2502 is not listening. I have tried basic tweaks such as rebooting and running IE as administrator, which have not helped. I've also confirmed that the same command line allows me to debug a standalone Java application.
I'm running JDK 8 and IE 11 on Windows 7.
I'm wondering if IE interfaces with Java slightly differently, so it doesn't obey the Runtime Parameters I have specified in the Java Control Panel.
I'm experiencing this weird problem that the JVM hangs forever very frequently.
I first observed the problem when my Java IDEs frequently hang the entire system GUI. IntelliJ IDEA hangs on indexing almost every single time upon start. Sometimes it proceeds to resolving dependency but always hangs in the end. When this happens, I can type in gnome-terminal, but the commands can't seem to be executed. I can't launch new applications with Alt-F2 or anything alike.
I had to switch to a text console and "killall -9 java" to kill the IDEA process and get control back. "kill -3 java" won't work. The log file contains nothing related, the thread dump is empty. Once the IDE hung, jstack cannot be attached to the process. "jstack -l pid" also hangs. "jstack -F pid" can't attach to the process. Visualvm hangs as well.
The CPU usage by the Java process is 0% and there is no I/O going on.
I've observed the same behavior when using Eclipse. Sometimes it hangs on start up, sometimes upon saving and sometimes upon running a Java application.
Maven / sbt builds executed within text-only ttys cause the same kind of hang, so I guess it's not a window manager / desktop environment / display driver problem.
I highly suspect it's a file system or I/O issue but I have no clue how to debug that. I've tried fsck with no luck, and my system works perfectly fine when not running java programs.
Things I've ruled out:
Permission issues: running IntelliJ with sudo doesn't help, hangs 100% of the time.
Display driver: I've tried both the Nvidia proprietary driver and nouveau, the open source one. Doesn't help.
Window manager / desktop environment: I use Cinnamon, but I've tried running IntelliJ under Unity. Doesn't help.
Java version: I've tried both Oracle Java 7 and Oracle Java 8. I'll probably try OpenJDK but I doubt it would work.
IntelliJ version: I've tried IntelliJ 13 through 14.1. All exhibited the same behavior.
Limited memory: I have 16G RAM with 16G swap space, so memory should not be a limiting factor.
Kernel log doesn't look suspicious. I can't get any kind of log remotely indicating what went wrong.
Any idea?
UPDATE (2015/04/29): The problem seems to have fixed itself after I accidentally kicked the power cable and cold restarted the computer... Still a mystery but IntelliJ is usable as of now.
Some things to check
- The Java IDEs run best with a lot of ram. I usually ask for at least
8G of memory for my dev workstation.
- Make sure you have a stable version of everything, look for known working versions/configurations on Ubuntu
- You have to manually allocate memory in IntelliJ IDEA versions < 14. For example: How to increase IDE memory limit in IntelliJ IDEA on Mac?
- Besides system logs, run tools like top and see what's happening in terms for cpu and ram when running the IDE
I had similar problems a while ago but with Eclipse. The problem was that there was no swap place at all ;) - obviously it should not be a problem with 16GB of RAM.
Could You post JVM arguments for Intellij? And also I have an idea to create another Intellij installation (eg. go back to 14 version) and see if there is similar problem (also compare JVMs settings between these two).
Edit
Ok so try:
use different JRE/JDK. If the problem disappears it will tell us more.
You are on linux so it makes it easy to monitor several things - you said that there is no CPU utilization or hard I/O. But how do you know that? Maybe it will be informative to have some statistics gathered - eg.jstat for JVM itself or for system information (You think that is I/O problem) try:
iostat -hm -p sda 1
Which will print I/O statistics for sda (if you have different discs change device parameter) in 1sec loops (can be also changed). Start this with system and dump output to the file - maybe there is some kind of 'disaster' happening before JVM hangs. Note: iostat sometimes is not available on system itself (on my Linux Mint is not) - install then package sysstat and the command will be available.
Seem to have fixed after a cold restart from an accidental power loss.. Weirdest problem I have ever seen.
I assume the question is strongly related to this one but it is closed and the solution does not seem clear to me.
I am trying to use VisualVM to profile a console Scala application of mine. I do this by starting VisualVM, starting my Scala application, opening its node in VisualVM, going to the "Profiler" tab and clicking "CPU". The button goes grey for some time (while status never changes to anything from "profiling inactive"), then back active but no profiling data appears shown.
The application does some file reading, data processing (which takes about a minute), stdout data output and exits. I've also tried adding Thread.sleep(60000) to the beginning and to the end of the program to ensure enough time for VisualVM to capture it and do the job, nothing changed though.
Unlike to the related question I've linked to I don't launch my app from Eclipse or anything else - I use the following command line to launch it:
java -classpath myapp.jar:lib/* MyApp.Main
all the libraries (including scala-library.jar) are put in lib/. The app works as expected.
Updates:
I have tried YourKit Java Profiler 11.0.2 and it fails with AttachNotSupportedException.
I've managed with YourKit by attaching the agent manually.
It seems worth stressing that I neither run the application from an IDE (or a build tool) nor have I modified any JVM options but classpath. As far as I understand this problem appears to depend on a JVM version and user/permission issues and. The objective is to figure out the actual mechanism of the problem and the way to configure all the things to work.
Versions of the software used:
YourKit Java Profiler 11.0.2
VisualVM 1.3.4
SBT 0.12.3 (to build but not to run (I've tried both actually))
Scala 2.9.2
Oracle Java 1.7.0_04-b20
XUbuntu Linux 12.04 32-bit i386
Linux kernel 3.2.0-24-generic-pae
I have used VisualVM to profile a Scala application two days ago, so I believe it should work. Here are my suggestions:
Take out YourKit out of the equation and run things without it for a starter
Take out scala out of the equation, try profiling a Java hello world that does while (true) { Thread.sleep(10000); }
Get that to work then put back Scala, then put back YourKit.
Edit: based on your input, I suggest to explicitly set the remote JMX connection. You can start java with the following options:
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=20000
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Then in VisualVM, add a JMX connection to localhost:20000.
I've built a RCP-based application, and one of my users running on Windows XP, Sun JVM 1.6.0_12 had a full application crash. After the app was running for two days (and this is not a new version or anything), he got the nice gray JVM force exit box, with exit code=1073807364.
He was away from the machine at the time, and the only thing I can find near that time in the application logs was some communication with the database (SQL Server by way of Hibernate). There's no hs_ files or anything similar as far as I can tell. Web searching found a bunch of crash reports with that exit code in a variety of applications, but I didn't see any fundamental explanation of what causes it.
Can anyone tell me what causes it? Is there additional information likely to have been dumped that could prove useful?
From what I can tell, this error code (0x40010004) arises in all sorts of situations, with (as you noted) no obvious common thread.
However this page says "0x40010004" means "the task is running"! So, I would surmise that the correct way to interpret it is as saying "this tasked has exited in a way that prevented it setting a proper exit code".
I don't know if this will help, but I would try looking in the Windows Event logs to see if the problem is being reported there.
When a Java VM crashes with an EXCEPTION_ACCESS_VIOLATION and produces an hs_err_pidXXX.log file, what does that indicate? The error itself is basically a null pointer exception. Is it always caused by a bug in the JVM, or are there other causes like malfunctioning hardware or software conflicts?
Edit: there is a native component, this is an SWT application on win32.
Most of the times this is a bug in the VM.
But it can be caused by any native code (e.g. JNI calls).
The hs_err_pidXXX.log file should contain some information about where the problem happened.
You can also check the "Heap" section inside the file. Many of the VM bugs are caused by the garbage collection (expecially in older VMs). This section should show you if the garbage was running at the time of the crash. Also this section shows, if some sections of the heap are filled (the percentage numbers).
The VM is also much more likely to crash in a low memory situation than otherwise.
Answer found!
I had the same error and noticed that others who provided the contents of the pid log file were running 64 bit Windows. Just like me. At the end log file, it included the PATH statement. There I could see C:\Windows\SysWOW64 was incorrectly listed ahead of: %SystemRoot%\system32. Once I corrected it, the exception disappeared.
First thing you should do is upgrade your JVM to the latest you can.
Can you repeat the issue? Or does it seem to happen randomly? We recently had a problem where our JVM was crashing all over the place, at random times. Turns out it was a hardware problem. We put the drives in a new server and it completely went away.
Bottom line, the JVM should never crash, as the poster above mentioned if your not doing any JNI then my gut is that you have a hardware problem.
The cause of the problem will be documented in the hs_err* file, if you know what to look for. Take a look, and if it still isn't clear, consider posting the first 5 or 10 lines of the stack trace and other pertinent info (don't post the whole thing, there's tons of info in there that won't help - but you have to figure out which 1% is important :-) )
Are you using a Browser widget and executing javascript in the Browser widget? If so, then there are bugs in some versions of SWT that causes the JVM to crash in native code, in various Windows libraries.
Two examples (that I opened) are bug 217306 and bug 127960. These two bug reports are not the only bug reports of the JVM crashing in SWT, however.
If you aren't using the Browser widget then these suggestions won't help you. In that case, you can search for a list of SWT bugs causing a JVM crash. If none of those are your issue, then I highly recommend that you open a bug report with SWT.
I have the same problem with a JNLP application that I have been using for a long time and is pretty reliable. The problem started immediately after I upgraded from Windows 7 to Windows 10. According to my investigation, it is most likely a bug in Win 10.
The following is not a solution, but an ugly workaround. In jre/bin directory, there is javaws.exe. If I right-clicked /Properties/Compatibility and ticked Run this program as an administrator, the JNLP app started to work.
Please, be aware that this approach could cause security issues and use it only if you have no other option and 100% know what you are doing.