Prev: multi-threaded quicksort
Next: How to persist print dialog settings?
From: Paul Geisler on 6 Dec 2009 00:04
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
From: Kevin McMurtrie on 6 Dec 2009 02:14
In article <7o0sb6F3o39juU1(a)mid.uni-berlin.de>,
Paul Geisler <paul.geisler(a)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
From: Owen Jacobson on 6 Dec 2009 02:42
On 2009-12-06 00:04:38 -0500, Paul Geisler <paul.geisler(a)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

From: Mike Schilling on 6 Dec 2009 21:13
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.


 | 
Pages: 1
Prev: multi-threaded quicksort
Next: How to persist print dialog settings?