I've built a RCP-based application, and one of my users running on Windows XP, Sun JVM 1.6.0_12 had a full application crash. After the app was running for two days (and this is not a new version or anything), he got the nice gray JVM force exit box, with exit code=1073807364.
He was away from the machine at the time, and the only thing I can find near that time in the application logs was some communication with the database (SQL Server by way of Hibernate). There's no hs_ files or anything similar as far as I can tell. Web searching found a bunch of crash reports with that exit code in a variety of applications, but I didn't see any fundamental explanation of what causes it.
Can anyone tell me what causes it? Is there additional information likely to have been dumped that could prove useful?
From what I can tell, this error code (0x40010004) arises in all sorts of situations, with (as you noted) no obvious common thread.
However this page says "0x40010004" means "the task is running"! So, I would surmise that the correct way to interpret it is as saying "this tasked has exited in a way that prevented it setting a proper exit code".
I don't know if this will help, but I would try looking in the Windows Event logs to see if the problem is being reported there.
Related
A quick answer would be "without crying" of course :).
I have a really strange problem with my Java application (J2SE 1.7) on a Win7 32bits system. I encountered all the cases :
Sometimes it goes out of memory of Java heap (and so I can log it and recover from this)
Sometimes it crash in the native and I have the hs_err_pidxxxx.log file and I can analyze what is going on.
Sometimes it crash in the native and I have no hs_err file but I have a popup java stop functioning and I can see the exception in windows event log and even debug with visual some part of the process.
Sometimes it crash and I have nothing (no hs_err, no popup, nothing...). It just ends all like if there were an System.exit() or a native exit() call.
So my question is :
how can I be sure this is a native exit call as I don't have all the code of native libraries I am using ?
Is it possible to have this strange behaviour produced by another mean ?
Finally how to debug and track which lib can be the root cause ?
how can I be sure this is a native exit call as I don't have all the
code of native libraries I am using ?
The only way I know to be sure would be to wrap the call to a native library with logging commands so you log before each call and after each return. After your program has crashed if the log has an enter message but no return message then that library call is suspect.
Is it possible to have this strange behaviour produced by another
means ?
Yes there are an infinite number of strange other means.
Using up memory or some other resource might be one explanation.
Finally how to debug and track which lib can be the root cause ?
Logging described above should find this too if the messages are specific to which library is being called. You can monitor the application in jconsole to see if it is using up tons of memory or threads. Disable anything that can be disabled so you can eliminate it as being part of the problem. If the problem goes away enable things one at atime until the problem returns.
How can I be sure this is a native exit call as I don't have all the code of native libraries I am using?
Debug it.
Is it possible to have this strange behaviour produced by another mean?
Hard to tell... Could be threading, could be memory leak, ...
Finally how to debug and track which lib can be the root cause?
Run Java with
-XX:+CreateMinidumpOnCrash
and you'll get a crash dump that you can analyze. Or use
-XX:+UseOSErrorReporting
to let Windows handle the crash (which will e.g. show a message to attach a debugger, depending on what you have installed. It might as well show "Send to Microsoft" error report.).
I have some issues with my PC and don't know what else to check or look for.
If the tags or description are off, feel free to edit/comment.
Basically the question is: Do you know of any tool that I could run during reproduction of the test, which logs frequently and might provide a hint on what's going on?
If anyone already has a clue of what could cause the problem, that would be great as well.
So here's the problem:
I have a running JBoss 4.2.3.GA server application which provides some EJBs with remote interfaces. Those EJBs write or read stuff to/from the database but that doesn't seem to matter since I also had methods that just did a System.out.println(...) and nothing more.
Now I run a test client from the console which basically just "remotely" calls one of those EJB methods in a loop (to take some timings etc.).
So far nothing too unorthodox should be done, it's basically just a bunch of remote EJB calls.
However, during the execution of the loop the computer freezes completely (keyboard doesn't respond as well, e.g. num-lock key) - the only thing that changes is the blinking cursor. :)
Unfortunately I didn't manage to find a reason for this and since I often do my tests from eclipse I'd like to not have that happen too often (workspace crashes etc.)
Here's what I tried so far:
Numerous hardware tests including Lenovo PC Doctor (it's a Lenovo PC) - all succeeded, so i seems like there's no hardware problem
Use different JDK versions: 1.5.0, 1.6.0, 1.7.0 - all crashed
JRockit JVM (Java 6) - crashed as well
make Java cause 100% CPU load (10 thread running constantly on 4 cores) - succeeded/no error
allocate as much memory as the JVM would allow me - succeeded
run the tests on other computers - succeeded, except one that has the same hardware and similar software setup
Windows logs don't provide a hint (except "system was not shut down correctly" ... well that helps :) )
After all these tests I assume it might be a problem with the system configuration (drivers etc.) but I don't know how to track that (and I can't just use brute force due to the massive time requirements).
So, did anyone experience similar problems?
Do you know of any tool that I might use to log what the system does and preferably get a log right before the crash?
Thanks in advance,
Thomas
A project I am currently involved in uses JavaCv/OpenCv for face detection. Since the OpenCv occasionally throws an error, and the propagation of OpenCv/C++ errors to Java Exceptions isn't fully functional yet, this means the Java main-loop crashes with no way to recover.
However, the code gives mostly accurate results, and since we're running it on a large database I baked a quick Batch-script around the execution to keep it going, and the Java code internally manages an id, to make sure it continues from just after where it crashed.
:RETRY
java -Xmx1024m -jar Main.jar
IF ERRORLEVEL 1 GOTO RETRY
EXIT 0
However, occasionally I get a Runtime Error pop-up, as follows:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: C:\Windows\System32\java.exe
This application has requested the runtime to end in an unusual way.
Please contact the application's support team for more information.
At which point the code execution halts until the pop-up is clicked, which is really annoying, as it means my code can't run without me babysitting it.
I found this question, which basically asks the same thing. There is an accepted solution for that question, but since I'm not directly working with C++, I don't see how I can implement this.
Is there a Batch-level solution to this problem? Is there a Java/JavaCv-level solution to catch the C++ errors coming from OpenCv? Any other solution?
Interesting question.
Java.exe is dependent on one or more of Visual C++ DLLs (like MSVCRT.DLL, msvcr90.dll etc). Probably the JAR file is causing Java.exe to cause this error. Java.exe must be calling some CRT function which is raising the exception and hence the Runtime Error.
The best bet you can do is to launch the process, let this error pop and then start Process Explorer, and see the call stack. Nevertheless, solving this issue is most probably out of your control. May be latest version of Java may help.
I have a dotnet process that through calls to an unmanaged dll is communicating with a Java process.
Under some circumstances, the Java process appears to be crashing and taking my dotnet process down with it. No exceptions are raised, the process just dies. Upon crashing, java is creating a log file with names like "hs_err_pid3228" etc.
Not having received any satisfaction from the vendor that is providing the unmanaged dll and the java process, I am reduced to trying to mitigate the problem which would necessitate ensuring the calls into the java process, if they crash, don't take down my process.
Having read various articles, appdomains seem a likely candidate to use - my theory being I can with a bit of work separate my functionality that calls the java process and run it in a separate appdomain, which will hopefully allow me to if not catch the appdomain going down, at least detect that it has happened and restart that functionality.
Has anyone had a similar sort of issue? Does this approach seem reasonable to those of you with more experience of appdomain?
To make it even more fun, the Java crash is not really reproducible - it seems very random and I'm still battling with how I'm going to TEST that separating into the appdomain
This is a reasonable use of AppDomains, and what you propose will work.
In a similar vein, I once used AppDomains to create a single application that watched for itself crashing for exception reporting purposes. The application started itself up, created a new AppDomain, then re-executed itself in the new AppDomain, which then detected it was running in an AppDomain and executed normally. When an exception happened in that AppDomain, the original process is notified, it tears down the child domain reports to the user that an error occured, asks whether they want to report it or not, then picked itself up and tried it all over again.
EDIT: To give you a headstart, if you want to look at the Program.cs for that project, I've uploaded a stripped down version here. (It's pretty long, so I didn't think I should post it here.)
Yep, leveraging AppDomains make a lot of sense here.
I've recently reworked my Windows service to load its various WCF services as plug-ins that operate within their own AppDomain. I've got a few cases in the bootstrapping process where I'm using MarshalByRefObject objects to get things up and running, but once the plug-ins are loaded, communication between the AppDomains is extremely easy using WCF.
When a Java VM crashes with an EXCEPTION_ACCESS_VIOLATION and produces an hs_err_pidXXX.log file, what does that indicate? The error itself is basically a null pointer exception. Is it always caused by a bug in the JVM, or are there other causes like malfunctioning hardware or software conflicts?
Edit: there is a native component, this is an SWT application on win32.
Most of the times this is a bug in the VM.
But it can be caused by any native code (e.g. JNI calls).
The hs_err_pidXXX.log file should contain some information about where the problem happened.
You can also check the "Heap" section inside the file. Many of the VM bugs are caused by the garbage collection (expecially in older VMs). This section should show you if the garbage was running at the time of the crash. Also this section shows, if some sections of the heap are filled (the percentage numbers).
The VM is also much more likely to crash in a low memory situation than otherwise.
Answer found!
I had the same error and noticed that others who provided the contents of the pid log file were running 64 bit Windows. Just like me. At the end log file, it included the PATH statement. There I could see C:\Windows\SysWOW64 was incorrectly listed ahead of: %SystemRoot%\system32. Once I corrected it, the exception disappeared.
First thing you should do is upgrade your JVM to the latest you can.
Can you repeat the issue? Or does it seem to happen randomly? We recently had a problem where our JVM was crashing all over the place, at random times. Turns out it was a hardware problem. We put the drives in a new server and it completely went away.
Bottom line, the JVM should never crash, as the poster above mentioned if your not doing any JNI then my gut is that you have a hardware problem.
The cause of the problem will be documented in the hs_err* file, if you know what to look for. Take a look, and if it still isn't clear, consider posting the first 5 or 10 lines of the stack trace and other pertinent info (don't post the whole thing, there's tons of info in there that won't help - but you have to figure out which 1% is important :-) )
Are you using a Browser widget and executing javascript in the Browser widget? If so, then there are bugs in some versions of SWT that causes the JVM to crash in native code, in various Windows libraries.
Two examples (that I opened) are bug 217306 and bug 127960. These two bug reports are not the only bug reports of the JVM crashing in SWT, however.
If you aren't using the Browser widget then these suggestions won't help you. In that case, you can search for a list of SWT bugs causing a JVM crash. If none of those are your issue, then I highly recommend that you open a bug report with SWT.
I have the same problem with a JNLP application that I have been using for a long time and is pretty reliable. The problem started immediately after I upgraded from Windows 7 to Windows 10. According to my investigation, it is most likely a bug in Win 10.
The following is not a solution, but an ugly workaround. In jre/bin directory, there is javaws.exe. If I right-clicked /Properties/Compatibility and ticked Run this program as an administrator, the JNLP app started to work.
Please, be aware that this approach could cause security issues and use it only if you have no other option and 100% know what you are doing.