How to generate crash dumps for JNI code

everyone,

Suppose I have a simple JNI program in Windows:

int* p = NULL;
*p = 5;

When run it from JVM, not like normal C++ application, JVM will nicely catch such hard exception and do some cleanup work.

The problem here is it also stops me from generating crash dumps right there, although there is a JVM option: -XX:OnError, but core dumps generated at开发者_如何学编程 this point is far from the crime scene thus hard to debug.

JVM wrap each Java thread using SEH:

__try
{
    thread.run()
}
__except(topLevelExceptionFilter())
{
}

JNI code which cause access violation happen in thread.run, but handled in topLevelExceptionFilter, which is already somewhere else.

Do you have any suggestions?

Thanks.

You can use the OnError Setting to start a native Debugger, like so:

http://download.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/clopts.html#gbmum

java -XX:OnError="gdb - %p" MyApplication

For Windows

There is also a -XX:+ShowMessageBoxOnError or -XX:+UseOSErrorReporting option for JDK7, not sure if it works for Linux core dumps, it should work for Windows and the default OS Debugger (DrWatson). See http://blogs.oracle.com/poonam/entry/more_on_windows_crash_dumps

A core is a C++ crash dump... you don't have the convenience facilities that Java provides to make it easier to work with. If you compiled your native code to retain symbols (and ideally to not be optimized) you can use gdb or another debugger to analyze it and obtain a stack trace at the point of failure, as well as read variables, etc.

core dumps generated at this point is far from the crime scene thus hard to debug -- core dumps are not "far from the crime scene" at all, they're fully comprehensive of the so-called crime scene. The only reason you think they're hard to debug is it's something you haven't learned yet... but they're definitely the right tool for this job.

In linux use ulimit - c unlimited to generate core dump Then use gdb to debug core file with java process.