I'm having a very odd issue with Java exiting abruptly and randomly.
I have a Macbook with M1 system (2021 model), with 32GB RAM. I'm running a Windows 11 (ARM64 Insider Preview) VM with Parallels. I have 16GB of RAM allocated for the VM, and 6 cores. I have Liberica JDK 8 (full with JavaFX) installed both on the host and the VM. I'm developing a multi-module Maven project, same project on both the host side and the VM side (the project depends on some Windows side things for some tasks, which is the reason I'm running the Windows VM on the side).
Output from java -version:
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (build 25.332-b09, mixed mode)
I've also tried with Azul JDK and had the same issue with it.
On the host side everything works as it should. Maven and Java commands both run successfully with no interruption or issues. On the Windows VM side however, it seems that Java just randomly exits with no error logs or anything really. I noticed it just hangs for a few seconds, and then just exits abruptly. I noticed that it may happen while running a Maven command, or for example running a .jar package with java -jar. Here's a picture of what it looks like (same happens on the picture above though):
A couple weeks back I had no issues at all. But then I had to reinstall Parallels and the VM (reinstalled the whole W11 OS), and suddenly these issues started occurring. I've tried adding -XX:+HeapDumpOnOutOfMemoryError to MAVEN_OPTS environment variable to see if it's a OutOfMemoryError, but it did not seem to have any results.
Any ideas?
In case anyone runs into this issue: I was able to resolve this issue by installing the Windows 11 VM into Parallels from an image downloaded from UUP Dump.
I tried reinstalling the VM downloaded from the Microsoft's Insider Preview page, but the issue still persisted and nothing seemed to be able to fix it. Java still exited randomly pretty frequently.
I downloaded the latest Windows 11 image from UUP Dump and installed that one instead. Installed the exact same versions of Maven, Java, Groovy etc. and surprisingly, the issue vanished. I've been able to run Java on my VM for a day now without issues, whereas with the image downloaded from Microsoft I was able to reproduce the issue pretty much within minutes after configuring my environment and cloning the Git repo of the project I'm developing.
A lot improved for me after switching to ARM64 Java (Microsoft's was first one I found, there may be others).
Some background: not sure if I had exactly the same issue, but vscode compiling and code checking was slow and unreliable, and my Mendix Java application kept crashing or not even starting. Since that uses Java 11, that's what I installed the ARM64 version of. This is in Windows 11 ARM, from Microsoft's Preview page, updated (hang the first try, but worked the second).
Related
I just upgraded form Java 1.7.51 to Java 8 and Eclipse stopped running. I made the changes and explicitly declared the VM (as you can see in the image). It started with an error that VM (2048MB) could not be allocated so I removed the XMX setting.
Is there something I missed? What have I done wrong?
It looks like you're trying to run the 64-bit version of Eclipse ("...launcher.win32.win32.x86_64") with a 32-bit JVM (It's in "Program Files (x86)"). Check to make sure you've installed the 64-bit version of Java 8.
I'm developing in Eclipse in Java and I noticed that the software execution in my eclipse is much slower (like 6 or 7 times) than the same code run in eclipse in another similar pc (both have 8gb ram 8 cores). The only difference is that I'm running on windows 7 and the other pc is running ubuntu 13.04.
I already checked and I'm using the right virtual machine (jre 1.7, the linux one is with jre 1.6) and there are at most about 20 prints on the console over a 6 minute run. Also I'm running as "run" and not debug.
What can it be? Is it possible that under linux is much faster?
UPDATE:
I installed a partition with Debian 7 on the same laptop with windows (where it was running slower). With both the default open jdk 1.6 and the new java 1.8 Debian is much faster. I would say ok if it was like 2 times slower, but a 6 minute execution instead of a 1 minute one is a bit strange.
Linux is in fact faster (usually) than Windows. It depends on alot of things though, RAM and cores are not only things that matter. CPU architecture, clock speed, OC or not and so on. If you´d post both computers specifications then it would be easier to answer but until then there's your answer.
One thing you can do is use a Terminal on each platform:
First do a java -version to make sure both are really using the Oracle JVM (for example, on Ubuntu, a trivial installation of Oracle JDK may not guaranee that you're not still using the original Open JDK).
Then, run your Java program in the terminal on each machine, and see if the difference persists. If it doesn't (i.e. if you only have the big performance gap when running from Eclipse), then it might be Eclipse's fault. While Java does tend to be faster on Linux/Debian vs. Windows, Eclipse might not have the same trend. If your experiment shows that Eclipse is the reason for the performance gap:
make sure that Eclipse is configured to use the Oracle JVM on each platform
make sure Eclipse itself and all it's possible plugins are updated (and if not, update first Eclipse, then its plugins).
I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?
The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer
The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.
"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!
I have a Java applet that downloads data from where it's hosted, using HTTP. The applet has default permissions for an applet, that is, not many. Randomly during download, maybe 90% chance of reproductibility, at a specific part of the log, the java executable hosted by Firefox will exit abruptly, and the Java Console will be closed.
I thought it was my first JVM crash after just a few weeks of Java, but could not find the Fatal Error Log. Until I found out that when Chromium is used to open the applet, it works 100% (many tries in various conditions, alterning with Firefox)
Both browsers execute use the same commandlines for the java executable
Firefox: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=20972388862 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.5712.287531591049678510.AF_UNIX
Chromium: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=20858056974 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.5428.6724684151611746860.AF_UNIX
Then I booted a Windows 2000 partition and also noticed that the applet was working 100% with the same version of Firefox and JRE. Could not try Chrome, not available on this platform.
Now I'm not necessarily asking for a solution as my 'client' will use Windows 2000 to run the applet. I was posting this to know if someone experimented with java crashes could find an explanation to this. Is it the communication between Firefox Linux and java that could make java exit? If you had to make this work, how would you proceed? Try to produce an SSCCE for Mozilla?
Versions:
Firefox 9.0.1 (both on Linux and Windows 2000)
Chromium 9.0.597.45 (70550) Built on Debian 6.0, running on Debian 6.0.2
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
EDIT: I found more information. When listening to Firefox's stderr, running the applet and then exiting Firefox after java exits, I get this. Not so useful though, it just tends to show that Firefox didn't even know that java exited.
Exception in thread "main" netscape.javascript.JSException: Plugin instance for applet ID 1 was already released
at sun.plugin2.main.server.LiveConnectSupport.getInfo(LiveConnectSupport.java:405)
at sun.plugin2.main.server.LiveConnectSupport.shutdown(LiveConnectSupport.java:41)
at sun.plugin2.main.server.JVMInstance.unregisterApplet(JVMInstance.java:1300)
at sun.plugin2.main.server.JVMInstance.recycleAppletID(JVMInstance.java:385)
at sun.plugin2.main.server.JVMManager.recycleAppletID(JVMManager.java:316)
at sun.plugin2.main.server.MozillaPlugin.stopApplet(MozillaPlugin.java:325)
at sun.plugin2.main.server.MozillaPlugin.destroy(MozillaPlugin.java:225)
Try to produce an SSCCE for Mozilla?
Yes. (I recommend that.)
You will need it for a bug report to either Oracle or Mozilla. Unless reported, problems do not get fixed.
I'm on a team of 6 developers and we are all using Eclipse Indigo on Ubuntu 11.04. At least once a day, if Eclipse is running, each of us experiences a total system lock-up. The only cure is a hard reboot of the PC. Some of us have had it more than ten times in one day. This does not happen if Eclipse is not running, so I can confidently say that Eclipse is the problem.
I have tried increasing the memory available to Eclipse by going into the ecplise.ini and increasing the Permsize, MaxPermSize, Xms, and Xmx. This has made no difference and everyone's PC is still locking up.
Has anyone experienced this before? I could understand maybe on one PC, but it happens on every single PC!
Java version: java-6-sun-1.6.026 JDK version
Ecplise version: Indigo SR1 BuildID 20110916-0149
Ubuntu version: 11.04 64-bit
EDIT: Ctrl-Alt-FnX keys do not work once the PC has locked up.
EDIT: I've revisited the eclipse.ini settings and increase the memory some more. So far I haven't had a crash yet. I will use the other developers as guinea pigs, but I'm hopeful that these settings will stop the crashing.
-XX:PermSize=256m
-XX:MaxPermSize=512m
-Xms1024m
-Xmx2048m
This is not to resolve Eclipse problem... which might be happening because of some display issues I suspect.
Instead of hard reboot you can press keystrokes Ctrl+Alt+F1 together to reach console and there you can login to a text based terminal and kill the Eclipse process.
more a comment than an answer, but I cant add you a comment yet.
I'm kinda using the same setup: Ubuntu 11.04 64bit with Eclipse Indigo SR1 RC3 64-bit (buildid 20110909, didnt had time or need to update to a newer release yet, but RC3 is stable for me). Make sure, you have installed the 64-bit version of Eclipse.
OpenJDK in combination with Eclipse didnt went well for me, so I changed to java-sun jdk 1.6/7. Make sure Eclipse is not referencing to the OpenJDK installation instead of java-sun jdk.
I had some issues with Eclipse Indigo (pre SR1) freezing in combination with SVN Subversive/m2eclipse plugins. For me it got better with the SR1 (RC3), but still not perfect (a freeze now and then). A while later Subversive SVN had an update, and now it's stable again. In short: make sure, you have installed the newest plugin versions (use eclipse update sites, no local copies). Older versions might lead to the same problems I experienced.
What other plugins are you using, can you verify if your Eclipse crashes without any plugins installed?
Two other issues I'm aware of: with Ubuntu Karmic Koala (9.10) rendering UI elements was broken/lead to crashes as well (GTK_NATIVE_WINDOWS). Later Eclipse had problems with the native scrollbars (think it was with Ubuntu 10.10 or 11.04). I'm pretty sure, problem 1 aint an issue anymore with Eclipse Indigo + 11.04. Problem 2 I'm not sure if it was 10.10 or 11.04. But I still start my eclipse with the following script.sh and it works for me, you could give it a shot as well:
#!/bin/bash
export LIBOVERLAY_SCROLLBAR=0
export GDK_NATIVE_WINDOWS=false
exec $(dirname $0)/eclipse "$#"
Try upgrading the kernel to the latest version. I think this lock up is caused by the kernel bug detailed on this page https://bugs.launchpad.net/ubuntu/+source/linux/+bug/924905
While you wait for better answers, I would definitely try a virtual machine like Virtual Box to:
Try to see if I can replicate the problem in a Virtual environment, which is similar to your actual environment. This way you can see if the problem the combination of the versions of software that you're using or your physical hardware.
Run Eclipse through the VM. It may not crash and will prevent you from having to do a full re-boot of the system, until you determine what the actual problem is.
I have a similar problem. From time to time it happens that the complete X11 desktop freezes. I can still move the mouse but clicks on elements have no effect.
In this situation I switch to the text console and kill eclipse. After I did that, everything works again.
I am using a laptop with an Intel graphics chipset. So I tend to blame it on the the graphics driver.
I have other computers with different graphics hardware where I haven't noticed the problem, but I don't use eclipse that often on them. On all I am using Ubuntu 11.10 64bit with gnome or unity desktop.
I have the same issues. It is very inconvenient. I have just confirmed that killing eclipse fixes the issue for me.
However, I have found something strange in that I can still click on the stupid overlay scrollbars. It's like they have the focus of the entire system.
What seems to have fixed the issue to me was to install the gnome shell and start using gnome 3, then turn off the overlay scrollbars in the startup scripts for X. I installed gnome 3 for a separate reason and disabled the scrollbars because I find them annoying, but I do find that this has solved the problem for me. You may be able to get away with just disabling the scrollbars, information for which is readily available on google.