Problem background
When java integrates c++ sdk through jni, occasional crashes are found online. In order to facilitate the location of native (c++) crashes, sdk uses the google breakpad crash dump solution (Google's cross-platform crash dump and analysis framework and A collection of tools, breakpad supports windows, linux, macos, android, ios, etc. It is currently used by Google Chrome, Firefox, Google Picasa, Camino, Google Earth and other projects.), after updating the sdk, it was found that java would crash after starting.
root cause analysis
The final reasons were identified as follows:
- The jvm has registered a signal processing function. For example, StackoverflowError and NPE (NullPointerException) will receive SIGSEGV, and then the virtual machine does not choose to exit for these two exceptions, but does additional processing internally, which actually resumes the execution of the thread. Just throwing exceptions to the application layer (because these two errors are too common in jvm), jvm will not crash;
- SDK breakpad caught the signal and exited the process directly after writing the minidump;
Solution
As long as the sdk captures the signal and writes the minidump without directly ending the process, continue to throw exceptions and let the jvm capture and process them. One disadvantage of this solution is that a large number of minidump files may be generated during the running process. When troubleshooting the problem, use the last A minidump is enough.
Actual operation: MinidumpCallback callback returns false instead of succeeding.
Reference: Why thread crash does not cause JVM to crash (https://www.cnblogs.com/xiekun/p/16378063.html)