Re: catch native crash
On 2009-12-06 00:04:38 -0500, Paul Geisler <paul.geisler@web.de> said:
Hello,
any idea how to catch a crash in JNI / JNA adapted native code? I have
to use large code collections (codecs etc.) that are crash prone by
design (eg. they have to handle damaged media files etc.). So in case of
a trap/crash, the JVM should exit native code, throw an (maybe
unprecise) exception and go on as usual.
That depends on what you mean by "crash." A "hard" crash -- for
example, a segmentation fault, or a bus error, or an arithmetic trap
like dividing by zero -- can't be recovered from; the JVM can't simply
trust that its internal state was not corrupted by whatever error
caused the signal, so the VM exits. A "soft" crash, on the other hand
-- where the library aborts what it's doing in an orderly fashion,
normally by returning an error code to the caller -- can be recovered
from.
A library that causes hard crashes is buggy, regardless of the problem
it's meant to solve. Plenty of media codecs handle bogus data by
aborting the decoding process and reporting an error; since most media
formats have fairly well-defined specs, it's not even terribly hard to
make this happen. On the other hand, a library that causes a segfault
on bad input probably also contains security vulnerabilities that can
allow arbitrary code execution: bad juju, man, just don't do it.
This isn't really a Java-specific question. The same thing comes up
even if you're writing native code, and it's very difficult to write a
correct, useful handler for SIGSEGV and friends even when you control
*all* of the code in a process; it's nearly impossible when so much of
the code is outside your control (the JVM itself, the Java standard
library, libc, the codec libraries themselves...).
If you cannot accept your application crashing on a library crash, you
need you separate code that uses that library into its own process,
with the IPC headaches that come with that. The whole concept of
separate processes exists to protect programs from each others' errors
and failures. You should also file bugs with the authors of crash-prone
libraries and consider finding alternative implementations that aren't
so likely to bite you later.
Cheers,
-o