crash on cef init due to signal handlers conflict

[magreenblatt]

Original report by Anton Tarasov (Bitbucket: Anton Tarasov).

---

Reproducible on macOS (likely on Linux as well).

Chromium sets BSD signals (SIGBUS, SIGSEGV etc.) handlers, erasing previously set JDK handlers. This leads to sporadic crashes. The problem is known, it was first discussed here: #41/mac-jcef-frequently-crashing-in-thread

In JCEF it has been resolved via storing/restoring JDK handlers right after CEF has been initialised. However, the problem is still actual for the CEF init phase. Chromium has an option --disable-in-process-stack-traces that seems to fit - it just disallows Chromium to install the handlers. However, there’s another problem with passing this option in time.

Current JCEF approach assumes passing options via the callback - CefAppHandlerAdapter.onBeforeCommandLineProcessing. However the callback is called from CEF too late, after first signal handlers are already set (see chromium/services/service_manager/embedder/main.cc::SetupSignalHandlers).

It should be somehow possible to pass the option to CefMainArgs, right here:
java-cef/native/context.cpp::Context::Initialize

It seems like currently it’s not possible…