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.


Is there any (maybe native) library to implement this?


thanks very mutch

Paul

In article <7o0sb6F3o39juU1@mid.uni-berlin.de>,
 Paul Geisler <paul.geisler@web.de> wrote:

> 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.
> 
> 
> Is there any (maybe native) library to implement this?
> 
> 
> thanks very mutch
> 
> Paul

There's nothing you can do to trap crashes inside the JVM.  The crash is 
often an indirect symptom of the bug - innocent code failing when it 
hits corrupted data or a smashed stack.

You can use ProcessBuilder to execute the native code in an expendable 
process and pass data along stdin, stdout, and stderr.  I did this with 
a custom build of FFmpeg that was modified to stream data correctly (and 
crash a little less).  One FFmpeg process decoded and multiple FFmepg 
processes in parallel encoded at different bitrates.

For some reason it didn't work well on Linux.  Other processes became so 
starved of resources that the machine appeared to be dead until FFmpeg 
finished.  It worked fine on Solaris and MacOS X.
-- 
I won't see Goolge Groups replies because I must filter them as spam

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

Paul Geisler wrote:
> 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.
>
>
> Is there any (maybe native) library to implement this?

A vague thought: if you wrapped the existing JNI calls with C++ that 
catches the SegV (or whatever the crash amounts to) as an exception, 
and then reports that exception to the JVM nicely, you'd have some 
chance of contusing normal processing.  You'd very likely have a 
memory leak, since the unwinding of the stack would lose track of any 
memory allocated by the discarded stack frames, but if you're lucky, 
it's no worse than that (i.e. memory hasn't been scribbled over, the 
heap hasn't been used up, the number of files left open doesn't use up 
your process's quota, etc.)

A much more robust solution is, as others have suggested, to run the 
questionable code in a different process, so that after a crash its 
resources can be cleaned up by the OS.