title: Is it possible to debug core dumps when using Java JNI?
body: <p>My application is mostly Java but, for certain calculations, uses a C++ library. Our environment is Java 1.6 running on RedHat 3 (soon to be RedHat 5).</p>
  
  <p>My problem is that the C++ library is not thread-safe. To work around this, we run multiple, single-threaded "worker" processes and give them work to do from a central Work Manager, also written in C++. Our Java application calls the C++ Work Manager via a third-party product.</p>
  
  <p>For various reasons, we want to re-write the C++ Work Manager and workers.  I'm in favour of writing them all in Java, using JNI in each worker to call the C++ library.</p>
  
  <p>The main problem is what happens if the C++ library core dumps. Unfortunately, this is quite common, and we need to be able to see which line in our C++ library caused the problem, e.g. by examining a backtrace in something like GDB.</p>
  
  <p>My colleagues believe that it will be impossible to analyse the core dumps, because tools like GDB don't understand core files produced by Java.</p>
  
  <p>I hope that they're wrong, but I need to be sure before pushing my ideas further.</p>
  
  <p>What is the best way to analyse a core dump produced from Java/JNI?</p>