@filipnavara any chance you can think of a better way?

@filipnavara any chance you can think of a better way?

I'll think about it. That said, I observed it and never really considered it a bug... NRE in .NET is almost never intentional, so this essentially just caused double reporting. Depending on .NET runtime used (NativeAOT vs MonoVM) this may contain some useful information.

NRE in .NET is almost never intentional, so this essentially just caused double reporting. Depending on .NET runtime used (NativeAOT vs MonoVM) this may contain some useful information.

Thanks @filipnavara - I think that's a perfectly valid perspective.

Currently this PR simply suppresses all SIGSEGV exceptions... which runs the risk of suppressing some that come from native code (and aren't reported as NREs). We've got two sub-optimal options at this point:

1. Let the SIGSEGV errors bubble up (possibly duplicating NREs)
2. Suppress the SIGSEGV errors... prevents duplicates but possibly suppresses genuine native errors

I think we have to pick one of those as the default behaviour, at the very least. But potentially we could expose an option to let SDK users override the default choice we make, depending on whether they prefer to catch all/every error (but possibly some twice) or whether they're happy to let a few slip through the cracks but prevent duplicates.

What about providing an option to control whether or not segfaults are suppressed. If they are annoying and not providing value to the user, disable them otherwise leave them on. In my experience, segfaults were a rare thing so I would still want to see them in most cases.

What about providing an option to control whether or not segfaults are suppressed. If they are annoying and not providing value to the user, disable them otherwise leave them on. In my experience, segfaults were a rare thing so I would still want to see them in most cases.

I'm of two minds about this... not so much surfacing an option (which I think is probably a good idea) but what the default should be for that option (to suppress or not to suppress).

Any managed NullReferenceException is resulting in a SIGSEGV Segfault being captured by our native SDK... so these are not all that uncommon (evidenced by the fact that we've had quite a few users reach out about this). Those users obviously find it irritating to get both a NullReferenceException and a SIGSEGV error reported/captured and I'm sure we'd get less issues in GitHub if the default behaviour was to suppress these.

On the other hand, I think it would be safer to capture these so that people have visibility, by default... and let them deliberately suppress if they want to. Then at least they'd be aware of the dangers/risks in doing so. So maybe a bit more work for us, but safer for SDK users.