I have problems with JRE on Linux Debian 5.
JRE (sun 1.6 21) crash with SIGBUS on Debian 5 (kernel 2.6.26) during TEE-CLC java application execute.
TEE-CLC-10.1.0 is a java client application for Microsoft Team Foundation Server (TFS).
Here is the java virtul mashine command line:
exec java -Xmx512M -classpath
"$CLC_CLASSPATH" "-Dcom.microsoft.tfs.jni.native.base-directory=$BASE_DIRECTORY/native"
$RANDOM_DEVICE_PROPERTY com.microsoft.tfs.client.clc.vc.Main "$#"
When I try to execute the command (get files from server): tf get -r -force {branch_name} it start getting files and then minute or two later craches with the following error message:
A fatal error has been detected by the Java Runtime Environment:
SIGBUS (0x7) at pc=0xb77d3422, pid=29386, tid=3076802752
JRE version: 6.0_21-b06
Java VM: Java HotSpot(TM) Client VM (17.0-b16 mixed mode linux-x86 )
Problematic frame:
C [+0x422] __kernel_vsyscall+0xe
An error report file with more information is saved as:
/...../..../...../hs_err_pid29386.log
Segmentation fault.
I have about 900M free memory. I have checked limits: ulimit -a .
I have three other Linux Debian 5 computers and they works fine with the same settings.
I have checked everything . I don' t know why JRE don't work properly.
Does anybody have any idea how to handle it? What is wrong with JRE or with my Debian 5?
In my experience it is rare to get a faulty program to fail with a SIGBUS: error checking by compilers makes it hard to generate an odd memory address. The few times I've seen them recently was (IIRC) because I was using an incompatible shared library or .o file.
Is the LD_LIBRARY_PATH environment variable set for the executing program? If so, it might be causing the program to use an incorrect shared library.
Related
The main site of DCEVM didn't clearly explain how to install DCEVM on Linux. Running "java -jar installer.jar" in Linux (when accessed via PuTTy) gave me the following exception.
[admin#LINUXBOX jdk1.7.0_55]$ java -jar DCEVM-full-7u79-installer.jar
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:207)
at java.awt.Window.<init>(Window.java:535)
at java.awt.Frame.<init>(Frame.java:420)
at javax.swing.JFrame.<init>(JFrame.java:224)
at com.github.dcevm.installer.MainWindow.<init>(MainWindow.java:43)
at com.github.dcevm.installer.Main.main(Main.java:46)
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:207)
at java.awt.Window.<init>(Window.java:535)
at java.awt.Frame.<init>(Frame.java:420)
at java.awt.Frame.<init>(Frame.java:385)
at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1757)
at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1832)
at javax.swing.JOptionPane.getRootFrame(JOptionPane.java:1697)
at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:863)
at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:667)
at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:638)
at com.github.dcevm.installer.Main.main(Main.java:51)
If required, I am also ready to use a Virtual Box installed Desktop Linux to try it, which then I can copy (patched JDK) into my original Linux box thereafter.
So, how can I install DCEVM on Linux (for Java 7)? Do I need a Desktop-based Linux for that?
EDIT:
Here's the output of few commands suggested by the first answer by Sharad:
[admin#TESTBEDPEGSEARCH jdk1.7.0_55]$ echo $DISPLAY
[admin#TESTBEDPEGSEARCH jdk1.7.0_55]$ java -version
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
EDIT2:
I am using DCEVM in Windows for quite a long time.
echo $DISPLAY should print :0 . If it is not printing :0 Then you should set display variable using this command "export DISPLAY=127.0.0.1:0.0" . I hope it will work
Step 1:--Check for the display variable set on your machine using echo
echo $DISPLAY
ensure It is set on :0
Step 2:-Check for your JAVA version Using
java -version
My Centos machine is reflecting:--
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (build 1.8.0_91-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
Step 3:-- I run java -jar DCEVM-full-7u79-installer.jar command
It works for me.
The DISPLAY variable is only set when a X11 session is active. When you login on a remote machine with ssh, this usually is not the case.
There are two possible solutions:
install a X server on Windows (e.g. XMing) and enable X11 forwarding in your Putty session (Connection > SSH > X11). This will show the installer on your Windows PC.
log in on the Linux host in a graphical session, this will automatically set the DISPLAY variable.
Note: I have not installed this but i happened to find a guide with video which may help you.
Please read the section with this heading Install DCEVM to hot redeploy more complicated changes
https://vaadin.com/blog/-/blogs/getting-started-with-vaadin-development-using-eclipse-maven
I am using android-studio in Arch linux 32bit from AUR.Recenty after latest pacman system upgrade , android-studio is refusing to start.Throws this error:
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x64056842, pid=645, tid=1686977344<br>
JRE version: Java(TM) SE Runtime Environment (7.0_72-b14) (build 1.7.0_72-b14)<br>
Java VM: Java HotSpot(TM) Server VM (24.72-b04 mixed mode linux-x86 )<br>
Problematic frame:<br>
C 0x64056842<br>
Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
An error report file with more information is saved as:
/home/joshua/java_error_in_STUDIO_645.log<br>
/usr/bin/android-studio: line 188: 645 Aborted (core dumped) LD_LIBRARY_PATH="$IDE_BIN_HOME:$LD_LIBRARY_PATH" "$JDK/bin/java" $AGENT "-Xbootclasspath/a:$IDE_HOME/lib/boot.jar" -classpath "$CLASSPATH" $VM_OPTIONS "-Djb.vmOptionsFile=$VM_OPTIONS_FILES_USED" "-XX:ErrorFile=$HOME/java_error_in_STUDIO_%p.log" -Djb.restart.code=88 -Didea.paths.selector=AndroidStudio1.4 $IDE_PROPERTIES_PROPERTY $IDE_JVM_ARGS $REQUIRED_JVM_ARGS $MAIN_CLASS_NAME "$#"
can anybody please suggest me how to fix this issue.Otherwise which package should I rollback so that it could work again?
Same here. I found this thread to be useful.
LD_PRELOAD=/lib/libglib-2.0.so studio.sh
However it seems like a workaround not a real solution.
EDIT:
Arch users:
wget http://pkgbuild.com/~heftig/glib2-2.46.0-2-x86_64.pkg.tar.xz
sudo pacman -U glib2-2.46.0-2-x86_64.pkg.tar.xz
Same error here!
Android studio 1.4.0.10-2
Arch linux
with jdk 8u60-1
EDIT:
Solved, after I changed the default java environments from java-8-jdk to java-8-openjdk.
A little late to respond to this post.I have similar problem with Android Studio 2.1.0 on linux OS (64 bit), studio crashing frequently . I tried to increase the size of JVM’s Heap by adding to gradle.properties file but it didn't help at all. I have updated java 1.8.0_77 to 1.8.0_92 now Android Studio works fine.
It sounds a strange question, but there is a reason.
I'm working to use VC++ code auto find out the max memory that JVM can use . I want to use java cmd to launch JVM simply.
My thoughts was:
Running java -Xmx3999G -version like commands and the output, if the JVM is launched successful, there will be something like
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Otherwise it will output something like
Error occurred during initialization of VM Unable to allocate
131039232KB bitmaps for parallel garbage collection for the r equested
4193255424KB heap. Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Now the key is that how to know whether the JVM is launched or not ? I can find some keywords in output like java version to get know it launched. But the output would be unstable if java update or something else.
The stable way I can think out is running a java code which has unchanged output (just print a simple string in main function can do this). But it needs me to package a jar file in my project's rc and extract it to temp folder and run it in cmd. I think it is little complex.
So I'm asking for help here , can any java command gives me a stable output if JVM is launched ?
How about java -help? Its output would always contain a list of commands, which surely contains a stable subset.
Other than that, you may still decide to retest once a new JDK version appears. It is imho highly unlikely that there are bigger changes in the output. Here's the output from java version 1.6.0_45:
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build
1.6.0_45-b06) Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode, sharing)
and here from java version 1.7.0_75:
java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) Client VM (build 24.75-b04, mixed mode, sharing)
These look very similar to 1.8.x except for the version number itself.
I downloaded the 32-bit eclipse for my 32-bit fedora 12. I extracted the tar.gz without any error. But when i click on the eclipse executable, i am getting the error:
"Failed to load the JNI shared library "/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/../lib/i386/client/libjvm.so"
"
I am not able to resolve this error. Please inform how to proceed.
Regards,
Go to your eclipse folder
Open eclipse.ini file and check if there is -vm option set properly
Else set -vm in one line followed by your jdk installed bin folder.
Hope this helps yo solve your problem.
I'd suggest avoiding OpenJDK, as Eclipse will keep complaining about it.
So, navigate to http://java.com/en/download/manual.jsp and download appropriate Sun's Java package (32 or 64 bit, depending on your current installation). As Fedora uses RPMs for package management, I advise to use that method.
Then, after installation, run java -version in terminal, you should get something like:
$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)
Could someone help me with this, I started using Eclipse only few days ago. I did google this problem, I see other people had the same "SIGSERV" crash but I did not find the way to fix it.
Eclipse Helios CDT under Ubuntu 11.04 crashes every time within a few seconds after I start it. It started happening after I cleared the check box: Index source files that are not included in the project.
Below is the error log. It's very long so I posted only the top part it.
THX!!
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ff5ccc6cc8b, pid=22977, tid=140693409957632
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.declaredBefore(Ljava/lang/Object;Lorg/eclipse/cdt/core/dom/ast/IASTNode;Z)Z
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x00000000416bd000):
JavaThread "Worker-7"
[_thread_in_Java, id=23044,
stack(0x00007ff5bca90000,0x00007ff5bcb91000)]
siginfo:si_signo=SIGSEGV: si_errno=0,
si_code=1 (SEGV_MAPERR),
si_addr=0x000000000165657a
could be several things, you might try out what of my students (Michael Rueegg) figured out during his master's project:
"After an Ubuntu system update on our CI environment, we regularly noticed broken unit tests which were caused by segmentation faults of the JVM. The update included the new JRE version 1.6.0_24.
The reason for this issue is partially described in the CDT bugzilla entry
https://bugs.eclipse.org/bugs/show_bug.cgi?id=333227 .
The proposed solution is to use a HotSpot option called UseCompressedOops. Oops stands for “ordinary object pointer” and is the equality of a managed pointer in HotSpot [Joh09]. This option is intended to reduce the memory usage of a 64-bit JVM by — among other provisions — encoding 64-bit pointers into 32-bits where possible [Joh09]."
[Joh09]
John Rose. CompressedOops - HotSpot Internals for OpenJDK. World Wide Web, http://wikis.sun.com/display/HotSpotInternals/CompressedOops , 2009. Accessed: 12.06.2011.
Hi I had a similar problem with Eclipse Indigo with CDT
I got the solution from here
http://www.eclipse.org/forums/index.php/m/664268/
add the following line to your eclipse.ini file
-XX:-UseCompressedOops