Why Does My Eclipse Luna 4.4 Crash on Debian Wheezy 7.4 with Oracle Jdk8 64Bit

Why does my Eclipse Luna 4.4 crash on Debian Wheezy 7.4 with Oracle JDK8 64bit?

According to:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736

Add to 2 lines eclipse.ini:

--launcher.GTK_version
2

The option --launcher.GTK_version should be before --launcher.appendVmargs

Problem (dialogs does not work properly) with TIBCO Jaspersoft® Studio - Visual Designer for JasperReports:

edit Jaspersoft Studio.ini like this:

-startup
plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar
--launcher.GTK_version
2
--launcher.library

Or add this before start Jasper Studio (runubuntu.sh):

export SWT_GTK3=0

grakn 1.0.0 cannot start queue on debian/wheezy with jdk8

I had the same problem. After failing to start, it created a file (like hs_err_pid20005.log) that said:

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 3720347648 bytes for committing reserved memory.

Seems like it's looking for ~3.7GB ! After freeing up some memory, it started fine for me.

Java 8 Application using all of System RAM and then crashing with a SIGBUS. Whats going on here?

Even though your program may indeed be correct in its usage of MappedByteBuffers, please note that at an high allocation pace you could incur phenomena due to untimely deallocation of said buffers, which is ultimately a responsibility of JVM and should occur only during garbage collection of buffers. In short, freeing of buffer will ultimately succeed but when it will happen should be hardly predictable.

You could, however, force deallocation ("cleaning") of memory allocated to buffers using JVM's Cleaner functionality (class sun.misc.Cleaner). Please refer to this SO question for some directions but, long story short, you simply should call Cleaner.clean() on your throwaway buffers as early as possible, in order to reduce memory allocation figures and support effectively your use case.

Java Unsupported major minor Version 52? Why does this happen though I didn't use new features from Oracle Java 1.8?

The version of the byte code doesn't depend on whether you use Java 8 new features or not. It simply depends on which compiler you use. A Java 8 compiler will by default produce Java 8 bytecode, unless you use the option -target to specify an earlier version.

Side note: your friend is not using the latest version of OpenJDK (which is Java 8), otherwise, he would not get this exception.

---

Related Topics