`sentry_options_set_handler_strategy` for native backend

[Thomas-Vos]

My app is a Kotlin (JVM) app, which also loads a Kotlin/Native .so library for easy native interop. I use sentry-java, however, as that does not pick up native crashes I also need sentry-native in the Kotlin/Native module.

It seems that on Linux, the JVM sends some (non fatal) signal events, which it normally picks up and handles. But with sentry-native installed, the sentry-native signal handling picks it up instead, which gets reported and now crashes the app. I figured out for the inproc backend I can use this to fix the issue:

sentry_options_set_handler_strategy(options, SENTRY_HANDLER_STRATEGY_CHAIN_AT_START)

I would like to use the native backend, so could this feature please be supported for native, too?

[linear-code]

NATIVE-204

[jpnurmi]

@Thomas-Vos Unfortunately, there are no guarantees that SENTRY_HANDLER_STRATEGY_CHAIN_AT_START works sensibly with JVM, but it would be interesting to dig deeper into this.

What kind of host platform is it? Desktop Linux? I wonder if it would be better to swap the signal handlers around by "pre-loading" sentry-native before the JVM runtime. It would probably give better results, because then JVM would be allowed to handle its own signals before sentry-native and thus, sentry-native doesn't need fragile heuristics for detecting non-fatal JVM-specific signals that have already been handled by JVM.

[Thomas-Vos]

Yes, it is desktop Linux (and Windows). I'm using compose multiplatform, and for easy native interop I am using a Kotlin/Native libary. It is also built as a GraalVM app.

I have been using sentry-native for quite some time already (inproc backend), but now I am updating it from 0.10.1 to 0.15.4 this is suddenly an issue. It worked fine before, so I guess something changed in sentry-native. It seems SENTRY_HANDLER_STRATEGY_CHAIN_AT_START resolves the issue, but I would have preferred to start using the native backend now.

Your suggestion sounds great, but I don't know how to pre-load sentry-native before the JVM runtime. I currently initialize sentry-native in my Kotlin/Native .so library, which I load in Kotlin (JVM) code as early as possible in main function using System.load. But of course that is already after the JVM is running.

I think for my use case, sentry_options_set_handler_strategy would be the easiest fix. What do you think?

[jpnurmi]

I have been using sentry-native for quite some time already (inproc backend), but now I am updating it from 0.10.1 to 0.15.4 this is suddenly an issue. It worked fine before, so I guess something changed in sentry-native.

Just a wild guess, but one reason could be SA_NODEFER added in 0.13.0:

• fix: split inproc handler thread #1446

Your suggestion sounds great, but I don't know how to pre-load sentry-native before the JVM runtime.

I'm not sure either, and not familiar with how the entry point of such an application looks, but I'd perhaps try combining the techniques from #1613 and getsentry/sentry-cocoa#6193 if there's a place where you could inject a constructor function:

extern void sentry__backend_preload(void);

__attribute__((constructor)) static void
onPreload(void)
{
     sentry__backend_preload();
}