I'm trying to run a program using Java 3d on a Raspberry Pi and I'm having some problems with the native libraries. I've found a version compiled for ARM on the debian website here
http://packages.debian.org/en/wheezy/armhf/libjava3d-jni/download
I've also tried the 'dfsg-9' version.
When I try and run the program the following output is printed:
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode)
A fatal error has been detected by the Java Runtime Environment:
SIGILL (0x4) at pc=0xa6e5b9e2, pid=7251, tid=3057575024
JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
Java VM: Java HotSpot(TM) Client VM (24.0-b56 mixed mode linux-arm )
Problematic frame:
C [libj3dcore-ogl.so+0x69e2] Java_javax_media_j3d_NativePipeline_getAWT+0x11
I don't really have any experience debugging problems to do with native code and am hoping for some advice on how to proceed with ths problem.
Thanks for reading.
Raspberry PI is based on an ARMv6 architecture processor. Debian armhf requires ARMv7 (or later). Hence an illegal instruction exception is exactly what I would expect.
Debian armel distribution works on the RPI.
However, if you are adding these packages to something like a raspian installation, that is unlikely to work, and you need to get your packages from a raspian repository.
The stacktrace indicates that your program triggered a SIGILL
SIGILL The SIGILL signal is sent to a process when it attempts to
execute an illegal, malformed, unknown, or privileged instruction.
Unless you wrote native code, this error is not your fault or doing. Try upgrading to the latest JDK (Java7 update 45) to see if this fixes it.
You can also try running your Java process with the -Xint flag to prevent any code from being dynamically compiled. Though not a long term solution, it may help identify where the error is happening. In your trace, it doesn't appear to be crashing in dynamically compiled code.
Related
I work on Rstudio running on a dedicated linux server. I get an error initialising h2o:
> h2o.init()
H2O is not running yet, starting it now...
<simpleError in system2(command, "-version", stdout = TRUE, stderr = TRUE): error in running command>
Error in value[[3L]](cond) :
You have a 32-bit version of Java. H2O works best with 64-bit Java.
Please download the latest Java SE JDK 8 from the following URL:
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
I checked the java config and got:
system("java -version")
openjdk version "1.8.0_77"
OpenJDK Runtime Environment (build 1.8.0_77-b03)
OpenJDK 64-Bit Server VM (build 25.77-b03, mixed mode)
Apparently I have the good version of java. I have found people with similar problems on Windows. They were able to solve the problem by finding and indicating the good java path. However in the environnement I am working in, i am not sure how to do that.
Any idea on how to solve the problem ? to bypass the error ?
Check if the JAVA_HOME environment variable is set. It may be pointing to the wrong spot, tricking H2O to find the wrong one.
You want JAVA_HOME/bin/java to be a good 64-bit java.
(The other thing you can optionally do is, when you do find a 32-bit java, uninstall it. There is no real reason to have it unintentionally anymore these days; memory sizes are much bigger than 15 years ago.)
I am trying to replace standard JVM of jdk1.8.0_112 with Dynamic Code Evolution VM using
DCEVM-light-8u112-installer.jar
but when i checked jvm version after patching with command
c:>java -version
it is still showing same Server VM as below
1 java version "1.8.0_112"
2 Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
3 Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
at line number 3, i am expecting type of Server VM as
Dynamic Code Evolution 64-Bit Server VM (build 25.71-b01-dcevmlight-10, mixed mode)
please guide me on this
The light version of the DCEVM project provides a single jvm.dll file that is a replacement for the default jvm.dll file included with Oracle/OpenJDK JDKs. The light version does not overwrite the file included with the JDK/JRE installation but rather installs the DCEVM JVM as an alternate implementation. Therefore, java -version will continue to show the default Java version details.
If DCEVM was installed successfully, java -version -XXaltjvm=dcevm will show the DCEVM version details, as expected.
java -version will return the DCEVM JVM version details if the full version of DCEVM is installed. Currently the DCEVM project provides full binaries only for Java 7. However, there is very little functional difference between the light and full versions so there is no real need to install the full version.
I have a problem with the VM from Java.
I installed on my PC Ubuntu 12.04 and installed the following Java version: OpenJDK Java6 Runtime.
I also installed the programm DigiESP.
DigiESP is an ID for a DigiModul. DigiESP is based on Eclipse. Now my
problem when I want to start DigiESP I got a error message:
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb11c9074, pid=3216, tid=3075950272
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b15 mixed mode, sharing linux-x86)
# Problematic frame:
# C [libxul.so+0x915074]
Normally I used a Windows PC, but now I need this program for a study project.
I don't know much about Ubuntu, so I could use help with this problem.
From the linked bug report, this may be caused by XULRunner version 2. As a workaround you may disable it, though I don't know which application components are using it.
-Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null
This system property will disable XULRunner for you.
im trying to build my JOGL project for linux here but eclipse console shows:
Info: XInitThreads() called for concurrent Thread support
and bamm the opengl context is not created...
java -version:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
To being able to help we would need more information,
as described in our Wiki:
http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing
After following our bugreport recommendations, we would have your test case
and the advertised log files sent by you. Either use our forum/mailinglist or bugzilla.
When done, you may be so kind and update this issue here at stackoverflow.
Note: Indeed, if your test fails with one of our test cases, it is most likely a JOGL problem. The most obvious test would be to try to run a native opengl demo ensuring its functional on your machine. However, please follow above procedure, then we maybe able to help. ~Sven
I am trying to get remote debugging working with Java on Solaris OS. Following is what I have tried-
I have a Java class called TestP which has the main method.
When I try
java -classpath . TestP
the program works fine. But when I try adding the debug parameters to the JVM-
java -Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n -classpath . TestP
It fails giving this error-
UTF ERROR ["../../../src/solaris/npt/utf_md.c":49]: Failed to complete iconv_open() setup
Can anyone please help me on figuring out why this error is coming up?? The above works fine on my Linux box.
Java version on Solaris:
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode)
Java version on Linux:
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-20.b16.fc10-i386)
OpenJDK Server VM (build 14.0-b15, mixed mode)
Hmm... This seems to be a known Solaris (not specific to Solaris 10) issue with Java 6, not a Java issue (see this thread).
Someone has successfully applied a workaround (see this blog post) from a Sun guy, Jeff Moguillansky, but I wouldn't recommend it and rather consider searching sunsolve for a patch as indicated on Sun's forums.
Look at this one: http://sunsolve.sun.com/search/document.do?assetkey=1-1-6586755-1 (you'll need a Sun Online Account with a valid Support Contract or Software Subscription).
Using truss I found out that the process was looking for /usr/lib/iconv/geniconvtbl/binarytables/UTF-8%646.bt and 646%UTF-8.bt, so I just copied ISO8859-1%ISO646.bt to UTF-8%646.bt and ISO646%ISO8859-1.bt to 646%UTF-8.bt (yes, it is "646", not "ISO646"!)
This is of course a very ugly workaround and I have no idea if it has any negative effects on the JVM, but at least it starts the JVM without aborting. (I did this on OpenSolaris 2009.06, btw)
If Pascal Thivent is right, then you may want to try running OpenSolaris (either on a blank machine or in a vm) and see if the problem is also there. If not, then consider using that version for now if possible.