Don't reset signal that hasn't been set
Once an in-process JVM is instantiated, it is vital that the disposition for SIGSEGV is not changed afterwards, as we do not make use of Java's libjsig.so (cf. <https://docs.oracle.com/javase/8/docs/technotes/guides/vm/ signal-chaining.html>) in our processes. I observed sporadic SIGSEGV crashes of CppunitTest_dbaccess_RowSetClones on a 64-core aarch64 machine (see comment at <https://github.com/flathub/ org.libreoffice.LibreOffice/issues/42#issuecomment-395731088> "OpenJDK 10 is now available"). What apparently happenes is that the cppunittester process first sets up its signal handlers through vclbootstrapprotector, which doesn't set one for SIGSEGV because bSetSEGVHandler is false in sal/osl/unx/signal.cxx because !is_soffice_Impl(). Then later when the in-process JVM is instantiated it sets its handlers, including a SIGSEGV one. Towards the end of the process, DeInitVCL calls osl_removeSignalHandler calls onDeInitSignal, which erroneously resets the SIGSEGV handler because it doesn't honor bSetSEGVHandler. But it can apparently happen that JVM threads are still running at that time and are executing JIT'ed code that can cause SIGSEGV that relies on the JVM's handler being installed, which it no longer is. (This can probably also happen for soffice.bin itself, where bSetSEGVHandler will be true. That will need a different, follow-up fix.) Change-Id: Ib6d99c23e57daa0b7576964908aadff511f2bb21 Reviewed-on: https://gerrit.libreoffice.org/56232 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Showing
Please
register
or
sign in
to comment