JVM crashes (2 stories about calling native library)

    I want to share two stories with the same plot, but different outcomes.
    Maybe someone whose JVM also crashes will be useful

    1. Native code is called from Java via JNI. Unit test - passes with a bang, the application (GUI, Swing) crashes.
    We are connected via the ddd debugger (this is such a shell over gdb, if one of the Java users does not know :)) - we see that it crashes with a long stack. We find out with the author of the native library that there they deserialize through the boost (such a library for C ++) a large glybin tree. And there is recursion.

    The idea arises (not immediately, 3 days of disputes and googling) that when you call from the application, the stack is larger and it overflows. Find the parameter for the JVM: -XX: ThreadStackSize =

    Works!

    2. Native code is invoked through JNA. There are callbacks back to Java, as I described . The unit test runs, the application crashes!


    Again - run ddd (the process is to call the debug version of the library to see the sources, launch the application from the debug environment, set the breakpoint in Java, when it stops to find the Java process number, connect to it from ddd, set breakpoints in it, continue execution in ddd, continue execution in Java - phew!)

    We see that it crashes when trying to call Java callback. How so?! I knew that it was impossible for the callback to collect gc and save it in the class field of its service!

    Another day of investigation, and it turns out:
    our craftsmen created another Spring Context in the application.
    Those.
    1. The “right” context was created, the spring bean of my service was born in it, it registered a callback
    2. The “extra” context was created, the other bean of my service was created in it (it is singleton, but only within the same context! In another context one istans!) and registered his callback
    3. GC collected an extra context, and with it my service, and with it callback
    4. I called my service (from the “correct” spring context), it called C, it called the callback. And it was recorded that he had already collected a scavenger callback from the “wrong” spring context!
    5. Crash!

    Remove unnecessary context - it works!


    Also popular now: