If a thread sets a shutdown hook using
Runtime.getRuntime().addShutdownHook();
calls via jna the method:
kernel32.CreateToolhelp32Snapshot (0x00000002, 0)
it crashes the VM.
If I call the same method in the
WindowListener.windowClosing()
hook, the call does not crashes the VM.
Any idea why?
I can post part of the VM crash error report if it could be of any use.
edit: see the VM crash report on pastebin
Posting the VM crash report should help.
Post part of the crash report on pastebin or the like maybe some can get some info out of that.
Well I don't know for sure but if you read the java doc for addShutdownHook()
Shutdown hooks run at a delicate time
in the life cycle of a virtual machine
and should therefore be coded defensively.
They should, in
particular, be written to be
thread-safe and to avoid deadlocks
insofar as possible. They should also
not rely blindly upon services that
may have registered their own shutdown
hooks and therefore may themselves in
the process of shutting down.
....
Shutdown hooks should also finish
their work quickly.
...
these leads me to the conclusion that maybe calling such a method either needs services from the JVM that aren't available anymore or that this call takes too long.
Related
Suppose I have a Java application that opens a database connection. Normally I would add a connection.close() in a finally block, but this block wouldn't be executed in the case of a kill operation, or any other abnormal termination, would it? Are there any other precautions that I, as a programmer, can make in order to close the connection properly before the application exits?
You should look at the Runtime.addShutdownHook() method for Java (http://java.sun.com/javase/6/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)). It allows you to add a hook that will be called when the virtual machine terminates. You can use it to call a cleanup routine.
That would be for a TERM signal though. A KILL signal will kill the process and not allow it to do any cleanup (because the KILL signal cannot be caught or ignored by the receiving process).
If something external kills your program, there's nothing you can do about it. Obviously they wanted to stop it, so how can you prevent them?
I was going to suggest a shutdown hook, but the Javadocs state:
In rare circumstances the virtual machine may abort, that is, stop running without shutting down cleanly. This occurs when the virtual machine is terminated externally, for example with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The virtual machine may also abort if a native method goes awry by, for example, corrupting internal data structures or attempting to access nonexistent memory. If the virtual machine aborts then no guarantee can be made about whether or not any shutdown hooks will be run.
(emphasis mine)
Killing a program will eventually timeout a TCP stream from your program to your [Oracle|SQL Server|MySQL|PostgreSQL] server.
The server will see it and rollback any pending transactions.
You shouldn't need to call connection.close() on application shut-down, since all open files will be closed automatically by the operating system.
Also, the Connection's finalize() method should be run before application shut-down automatically (if the shut-down is normal, not ABORTed), and that should close the connection.
In any case, you can register shutdown-hooks, to do any clean-up you require (again, will be run in normal shutdown cases, not ABORTs).
When you really get killed (kill -9 on UNIX), you can not do anything against that.
A finally-block is the most you can do, see SO: In Java, is the “finally” block guaranteed to be called (in the main method)? for details.
Some level of abnormal termination is unavoidable. How would you catch the event of the power cable being pulled on the server?
I'm working with Java Agent (creating a profiler) using code instrumentation (using Javassist for Instrumentation). I need to run few functions in my Java Agent profiler after the complete execution of java program. Something after the main function, like post-main (like we have premain). Is that possible?
There is no such thing as a postmain method and its semantics would not be clear either. Many programs run until they are killed. This requires the application to terminate and not to run different code.
Java offers shutdown hooks via the Runtime class that are triggered on an application's termination but which must not perform long-lasting operations. Also, they are not executed if a program is killed.
For a profiler, you would need to process data regularly and you could attempt to flush your buffers on termination without a guarantee.
I have a Java 1.6 application that accesses a third party native module, through a JNI class provided as the interface. Recently we noticed that a SEGFAULT is occurring in the native module, and is causing our application to crash. Is it possible to catch and handle this event, at least to log it properly before dieing?
I tried both Java techniques in the article from kjp's answer. Neither worked. Attempting to install a signal handler on 'SEGV' results in the exception
Signal already used by VM: SEGV
The shutdown handler I installed simply failed to fire, presumably because of what the IBM article states:
Shutdown hooks will not be run if
Runtime.halt() method is called to terminate the JVM. Runtime.halt() is provided to allow a quick shutdown of the JVM.
The -Xrs JVM option is specified.
The JVM exits abnormally, such as an exception condition or forced abort generated by the JVM software.
If all you want to do is log and notify you can write a script which runs your application. When the application dies, the script can detect whether the application terminated normally and from the hs_errXXXX file which has all the crash/SEGV information and mail it to someone (and restart the application if you want)
What you need to do is to run the faulty JNI code in another JVM and communicate with that JVM using RMI or JMS or Sockets. This way when the library dies, it won't bring down your main application and you can restart it.
Based on several weeks of research at the time, as well as conversations with JVM engineers at a conference this is not possible. The system will not let you install a SignalHandler on the SEGV signal.
Problem scenario : The problem is noticed in sonic MF container (The jvm).The container has hosted some java services responsible for db operations and message transformations.Once started, the container runs fine for 2-3 weeks and terminates by its own without throwing any exceptions.
After much research, we are unable to find out why or what has triggered the jvm (MF Container) to shutdown.
Is there a way by which I can get the thread dumps when the jvm goes down automatically ? I'm using java 1.6. Is there any other approach to this problem I should follow ?
Thanks in advance.
You could try java.lang.Runtime.addShutdownHook(), and have the hook iterate over all threads and dump their stack traces with Thread.getAllStackTraces(). However, if the JVM was shutdown by Runtime.halt() then the hooks won't be called. More complicated would be to use instrumentation to hook into the calls to Runtime.exit() and Runtime.halt() (or Shutdown.sequence(), see edit #2), so you can see exactly what's happening at the time that either is called.
EDIT: Another way of doing it would be to install a SecurityManager which doesn't enforce any security, but which dumps the list of threads whenever SecurityManager.checkExit() is invoked, since both halt() and exit() call that security manager method. This would be a lot easier than using instrumentation, and you could even decide to throw an exception in addition to logging what the threads are doing.
EDIT 2: The system the JVM is running on can tell the JVM to terminate, in which case using a security manager won't work. Nor will using instrumentation on Runtime.exit() or Runtime.halt(), since the method that gets invoked is java.lang.Shutdown.exit(). And if the JVM is shutting down because the last daemon thread finished then Shutdown.shutdown() is invoked. But shutdown hooks will work in either of those situations. So you should always use the shutdown hooks, even if you're also going to use the security manager or instrumentation.
See also https://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/hangloop.html "Troubleshooting Hanging or Looping Processes"
However, at least in my case, Eclipse is hung, and does not respond to any of these.
We have a Java App that connects via RMI to another Java app.
There are multiple instances of this app running at the same time, and after a few days an instance just stops processing... the CPU is in 0 and I have an extra thread listening to an specific port that helps to shutdown the App.
I can connect to the specific port but the app doesn't do anything.
We're using Log4j to keep a log and nothing is written, so there aren't any exceptions thrown.
We also use c3p0 for the DB connections.
Anyone have ideas?
Thanks,
I would suggest starting with a thread dump of the affected application.
You need to see what is going on on a thread by thread basis. It could be that you have a long running thread, or other process which is blocking other work from being done.
Since you are running linux, you can get your thread dump with the following command
kill -3 <pid>
If you need help reading the output, please post it in your original question.
If nothing is shown from the thread dump, other alternatives can be looked at.
Hum... I would suggest using JMetter to stress the Application and take note of anything weird that might be happening (such as Memory Leaks, Deadlocks and such). Also review the code for any Exceptions that might interrupt the program (or System.exit() calls). Finally, if other people have access to the computer, makes sense to check if the process wasn't killed manually somehow.