JVM crashes (2 stories about calling the native library)
I want to share two stories with the same plot, but different interchanges.
Maybe someone who also falls JVM will be useful
1. Native code is called from Java via JNI. Unit test - passes with a bang, the application (GUI, Swing) is crashing.
We are connecting via ddd debager (this is such a shell over gdb, if any of the javaists do not know :)) - we see what falls with the longest stack. We find out with the author of the native library that they deserialize there through boost (such a library for C ++) a large glibin tree. And there is a recursion.
There is an idea (not immediately, 3 days of disputes and googling) that when called from the application, the stack is larger and it overflows. Find the parameter for the JVM: -XX: ThreadStackSize =
')
Works!
2. Native code is invoked via JNA. Present Kolbeki back to Java, as I described . Unit test is running, the app crashes!
Again, we run ddd (the process is to call the debug version of the library to see the resources, start the application from the debug environment, put the breakpoint in Java, when it stops to find the process number of Java, connect to it from ddd, set breakpoints in it, continue execution ddd, continue to perform in Java - fuh!)
We see that falls when trying to call Java kolbek. How so?! I knew that it was impossible for gc to gather and save it in the class field of his service!
Another day of investigation and it turns out:
Our craftsmen created another Spring Context in the application.
Those.
1. A “correct” context was created, a spring bin of my service was born in it, it registered a colbek
2. An “extra” context was created, another bin of my service was born in it (it is a singleton, but only within one context! In another context, another istance!) And registered its own colback
3. GC collected an extra context, and with it my service, and with it a callback
4. I called my service (from the “correct” spring context), he called C, he called Kolbek. And a kolbek from the “wrong” spring context was already collected from him by the scavenger!
5. Crash!
We remove the extra context - it works!
Maybe someone who also falls JVM will be useful
1. Native code is called from Java via JNI. Unit test - passes with a bang, the application (GUI, Swing) is crashing.
We are connecting via ddd debager (this is such a shell over gdb, if any of the javaists do not know :)) - we see what falls with the longest stack. We find out with the author of the native library that they deserialize there through boost (such a library for C ++) a large glibin tree. And there is a recursion.
There is an idea (not immediately, 3 days of disputes and googling) that when called from the application, the stack is larger and it overflows. Find the parameter for the JVM: -XX: ThreadStackSize =
')
Works!
2. Native code is invoked via JNA. Present Kolbeki back to Java, as I described . Unit test is running, the app crashes!
Again, we run ddd (the process is to call the debug version of the library to see the resources, start the application from the debug environment, put the breakpoint in Java, when it stops to find the process number of Java, connect to it from ddd, set breakpoints in it, continue execution ddd, continue to perform in Java - fuh!)
We see that falls when trying to call Java kolbek. How so?! I knew that it was impossible for gc to gather and save it in the class field of his service!
Another day of investigation and it turns out:
Our craftsmen created another Spring Context in the application.
Those.
1. A “correct” context was created, a spring bin of my service was born in it, it registered a colbek
2. An “extra” context was created, another bin of my service was born in it (it is a singleton, but only within one context! In another context, another istance!) And registered its own colback
3. GC collected an extra context, and with it my service, and with it a callback
4. I called my service (from the “correct” spring context), he called C, he called Kolbek. And a kolbek from the “wrong” spring context was already collected from him by the scavenger!
5. Crash!
We remove the extra context - it works!
Source: https://habr.com/ru/post/114781/
All Articles