I am using JME in my application and sometimes it crashes with the following message:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x3d601ad7, pid=168, tid=4012
#
# JRE version: 6.0_29-b11
# Java VM: Java HotSpot(TM) Client VM (20.4-b02 mixed mode, sharing windows-x86)
# Problematic frame:
# C [ig4dev32.dll+0x21ad7]
#
# An error report file with more information is saved as:
# C:\...\hs_err_pid168.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
The log file can be found by this link: http://sergpank.heliohost.org/log.html
The strangest thing is that in my case I get crashes only ob builded code, but when I am launcing it from the Eclipse, everything works fine on my machine. On machines with AMD video adapters nothing crashes. On other machines with Intel videocard sometimes crashes appear and on the debug stage.
I am starting to suppose that this happens because of incorrect ant setup (in startup.ini the following path is set up: -Djava.library.path=lib/dlls so dlls is seen for the project). But still can't get why it works almost perfectly on AMD and crashes on Intel.
Maybe it is something related to the ant, and I have to add dlls to the manfest... looking through the documentation and can't find the way how it can be done.
Solution:
On 64 bit system is necessary to use the corresponding JVM(64-bit) and then nothing crashes =))
Crash happens because 32-bit JVM was used on 64-bit OS. It seems that in this case 32-bit dlls was loaded and that's why crash happened.
Issue is reproducible only on Intel video cards, I think it can be considered as a serious bug. If Intel would like to fix it or propose a working solution/workaround this could be great! =)
Avoid doing the heavy work of the OpenGL stuff in the Swing Event Dispatch Thread (note the thread which crashes the JVM: =>0x3a88e000 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=5228, stack(0x3b170000,0x3b1c0000)). I believe OpenGL stuff should be done in the thread offered by JMonkeyEngine using the event dispatch mechanism it has. If you're using somebody else's API for Swing rendering, you might need to change it or do it a different way.
Edit: it looks like AWTGLCanvas does this, changing the context to the current thread. It looks like the Intel drivers may have trouble with context switches if normal fullscreen 3D stuff works. Strictly speaking, the GL thread context stuff shouldn't be necessary as you can always dispatch work to be executed to a singular OpenGL thread which should be fine as long as you only have a single OpenGL rendering viewport. The LWJGL Canvas implementation assumes you will want multiple viewports when this isn't necessarily the case. You can recode this to only support one viewport if that is fine, and you shouldn't get crashes as the code is simpler.
Related
I'm writing a messaging app as my final project for 12 grade and I have an error that I have no idea how to even approach. I disabled and re-enabled features of the web app one by one to see when the error occurs, and I observed that when I try to bring the active conversations that one user has, my server crashes. This doesn't happen constantly, it seems like random occurrences. Here is the error message by the server:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000007034537d, pid=13536, tid=9944
#
# JRE version: Java(TM) SE Runtime Environment 18.9 (11.0.10+8) (build 11.0.10+8-LTS-162)
# Java VM: Java HotSpot(TM) 64-Bit Server VM 18.9 (11.0.10+8-LTS-162, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
SELECT * FROM conversations WHERE id1 = '1' OR id2 = '1' ORDER BY lastUpdate DESC LIMIT 9 OFFSET 0;#
CSELECT * FROM accounts WHERE id = 16;
[sqlite-3.30.1-03ac4057-b812-49a1-9a10-f02ba1c22986-sqlitejdbc.dll+0x537d]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\paRa\AppData\Local\Temp\\hs_err_pid13536.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
From what I saw on other posts, this error message should point where the error is located, in my case if I go to the specific lines where those SQL queries are executed, I have no error.
What it should be noted is that when I put a break point in the API of the activeConversations function, the server never crashes, so I was thinking that it had something to do with how much information is being handled. However, there isn't much information transferred at the moment since I don't have that much information in the database.
The most likely explanation (outside of a bug in sqlite) is that the JVM is running the webserver with a lot of threads but the sqlite configuration is using single threaded mode and thus causing memory corruption.
Check that you are starting/configuring the sqlite with at least multi threaded mode.
https://sqlite.org/threadsafe.html
Ok, so I want to mention that #AlBlue message was really helpful in resolving my problem. As he said my database (SQLite) was handling multiple requests at the same time, and so it crashed. Since I did not know how to configure sqlite to multi threading, I used a deffered object in jquery to make a function run after another. You can see what i used by clicking on this link: Jquery Deffered Function (site is not seccured btw, so be carefull, I will also post the code down below in the case some of you do not want to access the site:
var functionOne = function() {
var r = $.Deferred();
// Do your whiz bang jQuery stuff here
console.log('Function One');
return r;
};
var functionTwo = function() {
// Do your whiz bang jQuery stuff here
console.log('Function Two');
};
// Now call the functions one after the other using the done method
functionOne().done( functionTwo() );
Again thank you to everyone for the answers! I am recent to this platform and I do not how this procedure works. Since my answer is a solution to my problem, and not to the error itself, then I should give the correct answer to #AlBlue correct? I'll update the answer once somebody comments. I want to give propper credit!
Edit: I read the tooltip of the button =))
An access violation means that native code (in this case inside SQLite) is trying to access memory it is not allowed to access, this usually indicates a bug in that native library (or in another native component it is depending on). It is unlikely - though not impossible - the problem is in your own code.
As a first step, try to see if using a newer version of SQLite solves the problem. If that doesn't solve it, try to reduce the code necessary to reproduce the problem and report it either to the authors or SQLite or the SQLite JDBC driver you're using.
We have an Ada shared library compiled by GnatPro 19.2 that we're calling through a JNA call.
Our application runs fine under windows. When porting it under Linux, the application crashes randomly with an Ada exception:
storage error or erroneous memory access.
Debugging with gdb (attaching the process) doesn't help much. We get various SIGSEGV, we continue, and after a while we get the storage error with no useable call stack.
Our shared library can be used with a python native call without any issues whatsoever. The issue is probably on the Java side.
Tried switching JVM (openjdk or official jdk) without luck.
Why is this? Is there a way to workaround it?
The first hint is getting a bunch of SIGSEGV when trying to attach a debugger to the application, then seeing the program resuming when continuing.
It means that the SIGSEGV signal is handled on the Java side, as confirmed in Why does java app crash in gdb but runs normally in real life?.
Java uses speculative loads. If a pointer points to addressable memory, the load succeeds. Rarely the pointer does not point to addressable memory, and the attempted load generates SIGSEGV ... which java runtime intercepts, makes the memory addressable again, and restarts the load instruction.
Now what happens, is that by default, the GNAT run-time installs a new signal handler to catch SIGSEGV and redirect to a clean Ada exception. One interesting feature of Ada exceptions is that they can print the stack trace, even without a debugger. This SIGSEGV handler redirection allows this.
But in the case of Java, since Java uses speculative loads, SIGSEGV are expected from time to time on the java side. So when the Ada shared library has been loaded & initialized, the Ada SIGSEGV handler is installed, and catches those "normal" SIGSEGV, and aborts immediately.
Note that it doesn't happen under Windows. The java runtime probably cannot use this speculative load mechanism because of Windows limitations when handling memory violation accesses.
The signal handling is done in s-intman.adb
-- Check that treatment of exception propagation here is consistent with
-- treatment of the abort signal in System.Task_Primitives.Operations.
case signo is
when SIGFPE => raise Constraint_Error;
when SIGILL => raise Program_Error;
-- when SIGSEGV => raise Storage_Error; -- commenting this line should fix it
when SIGBUS => raise Storage_Error;
when others => null;
end case;
end Notify_Exception;
Now we'd have to rebuild a new native run-time and use it instead of the default one. That is pretty tedious and error prone. That file is part of gnarl library. We'd have to rebuild the gnarl library dynamically with the proper options -gnatp -nostdinc -O2 -fPIC to create a gnatrl library substitution... and do that again when upgrading the compiler...
Fortunately, an alternate solution was provided by AdaCore:
First create a pragmas file in the .gpr project directory (let's call it no_sigsegv.adc) containing:
pragma Interrupt_State (SIGSEGV, SYSTEM);
to instruct the run-time not to install the SIGSEGV handler
Then add this to the Compiler package of the .gpr file:
package Compiler is
...
for local_configuration_pragmas use Project'Project_dir & "/no_sigsegv.adc";
and rebuild everything from scratch. Testing: not a single crash whatsoever.
I have written a short application that converts files from their raw data to XML (ECGs). I have about 350000 files to convert, and the convertion itself is done via a library that I got from the manufacturer of the ECG devices. To make use of multiple processors and cores in the machine I'm using to do the convertion I wrote a "wrapper application" that creates a pool of threads, which is then used to do the convertion in separate threads. It works somewhat ok, but unfortunately I do get random errors causing the whole application to stop (85k files have been converted over the past 3-4 days and I have had four of those errors):
A fatal error has been detected by the Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x71160a6c, pid=1468, tid=1396
JRE version: Java(TM) SE Runtime Environment (8.0_20-b26) (build 1.8.0_20-b26)
Java VM: Java HotSpot(TM) Client VM (25.20-b23 mixed mode windows-x86 )
Problematic frame:
C [msvcr100.dll+0x10a6c]
I would suspect that it's the library that I'm using that causes these, so I don't think I can do all that much to fix it. If that error happens, I run then program and let it start where it left off before crashing. Right now I have to do that manually but was hoping that there is some way to let Eclipse restart the program (with an argument of the filename where it should start). Does anyone know if there is some way to do that?
Thanks!
It is not entirely clear, but I think you are saying that you have a 3rd party Java library (with a native code component) that you are running within one JVM using multiple threads.
If so, I suspect that the problem is that the native part of the 3rd-party application is not properly multi-threaded, and that is the root cause of the crashes. (I don't expect that you want to track down the cause of the problem ...)
Instead of using one JVM with multiple converter threads, use multiple JVMs each with a single converter thread. You can spread the conversions across the JVMs either by partitioning the work statically, or by some form of queueing mechanism.
Or ... you could modify your existing wrapper so that the threads launched the converter in a separate JVMs using ProcessBuilder. If a converter JVM crashes, the wrapper thread that launched it could just launch it again. Alternatively, it could just make a note of the failed conversion and move onto the next one. (You need to be a bit careful with retrying, in case it is something about the file that you are converting that is triggering the JVM crash.)
For the record, I don't know of an existing "off the shelf" solution.
It seems that you are using the x86 (32-bit) version of Java. Maybe you could try it with the x64 (64-bit) version. That has sometimes worked for me in the past.
The problem seems to be in the native library, but maybe if you try it with 64-bit Java, it will use a 64-bit version of the native library?
One day ago, after a few months of normal working, our java app starts to crash occasionally with the following error:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (safepoint.cpp:247), pid=2075, tid=140042095163136
# guarantee(PageArmed == 0) failed: invariant
#
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# An error report file with more information is saved as:
# /var/chat/jSocketer/build/hs_err_pid2075.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
I looked in hs_err_pid2075.log and saw that there was an active thread, that processed a network communication. However there wasn't any application or environment changes done in the last few months. Also there wasn't any load growth.
What can I do to understand, what is the reason of crash? Are there any common steps to investigate a jvm crash?
UPD
http://www.wuala.com/ubear/public
The crash is in the JVM, not in external native code. However, the operation it crashed on has been initiated by and external DLL.
This line in the hs_err_pid file explains the operation that crashed:
VM_Operation (0x00007f5e16e35450): GetAllStackTraces, mode: safepoint, requested by thread 0x0000000040796000
Now, thread 0x0000000040796000 is
0x0000000040796000 JavaThread "YJPAgent-Telemetry" daemon [_thread_blocked, id=2115, stack(0x00007f5e16d36000,0x00007f5e16e37000)]
which is a thread created by Yourkit. "GetAllStackTraces" is something that a profiler needs to call in order to do sampling. If you remove the profiler, the crash will not happen.
With this information It's not possible to say what causes the crash, but you can try the following: Remove all -XX VM parameters, -verbose:gc and the debugging VM parameters. They might interfere with the profiling interface of the JVM.
Update
Code that calls java.lang.Thread#getAllStackTraces() or java.lang.Thread#getStackTrace() may trigger the same crash
The two times I've witnessed recurring JVM crashes were both due to hardware failure, namely RAM. Running a memtest utility is the first thing I'd try.
I can see from the error report that you have the YourKit agent loaded. Its telemetry thread is mentioned as the requester for the operation that appears to fail. Try running the application without the YJP agent to see if you can still reproduce the crash.
Generally, JVM crashes are pretty hard to diagnose. They could happen due to a bug in some JNI code or in the JRE itself. If you suspect the latter, it may be worth submitting a bug report to Oracle.
Either way, I'd recommend to upgrade to the latest release of Java 6 to make sure it's not a known issue that's already been fixed. At the time of this writing the current release is Java 6 update 29.
If you're not messing with anything that would cause this directly (which basically means using native code or libraries that call native code) then it's almost always down to a bug in the JVM or hardware issue.
If it's been running fine for ages and has now started to crash then it seems to me like the hardware issue is the most likely of the two. Can you run it on another machine to rule out the issue? Of course, it definitely wouldn't hurt to upgrade to the latest Java update as well.
Switching to another version of linux-kernel "fixes" the JVM crush problem (http://forum.proxmox.com/threads/6998-Best-strategy-to-handle-strange-JVM-errors-inside-VPS?p=40286#post40286). It helped me with my real server. There was Ubuntu server 10.04 LTS OS on it with kernel 2.6.32-33 version. So kernel update resolved this issue. JVM has no crash anymore.
I have java aplication and it started to crash sudently, without no exception. But sometimes JVM creates crash log file, which has name like: "hs_err_pid10930.log". Can anybody read it and tell me what is wrong? I am not able to find out what si wrong. The only reasonable info which I find here is that swap size is 0. I that a problem? How could it occure?
You can find the file here: http://chessfriends-release.s3.amazonaws.com/logs/hs_err_pid10930.log?AWSAccessKeyId=AKIAJP5BYGKOCMCDVZHA&Expires=1305128715&Signature=XEZMuJ0xNSM6YTcdwsI04ahhiYk%3D
Thanks.
Libor
Whenever you get a crash like this it's almost never the Java programmer's fault because the JVM is crashing which it shouldn't. By looking at your log file, it looks like it's crashing somewhere in the OpenJDK's JVM; I don't know what specifically is causing it. I would suggest you try out Oracle's official JDK rather than OpenJDK.
I'm not an expert on reading these sorts of crash dumps, but this is the part I use to identify what is causing the problem:
# Problematic frame:
# V [libjvm.so+0x64d62d]
This is at the top of the dump. It's not always libjvm.so; I've seen some with like libGL.so.
If you would like to file a bug, the dump includes this statement:
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
I don't know what it is you're doing that causes the crash, and maybe there is a workaround. But under no circumstances should the JVM crash, so this is a bug in the JVM you're using.
Edit
The log says you're running Ubuntu 9.10; there have been two Ubuntu releases since then so I doubt filing a bug would do any good unless you test this out on either Ubuntu 10.04 or 10.10. I don't know if you're able to upgrade to a newer version, but your problem may have already been fixed.