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>