[android-devel] [macios-devel] Signal-chaining & crash reporters
Rolf.Kvinge at microsoft.com
Tue Sep 20 09:17:56 UTC 2016
I think we should first decide how we want to expose this in managed code, since using your idea I don't see any options besides those I initially proposed (and which Miguel didn't like).
One of the problems is that there's a lot of people involved here:
1) The native library that detects crashes and collects crash information. On iOS this is typically PLCrashReporter .
2) Companies that build native crash reporting solutions on top of libraries from 1). On iOS this is HockeyApp, Insights, Crittercism, Flurry (which all use PLCrashReporter I believe), Crashlytics (which is not using PLCrashReporter, they wrote their own replacement ), etc.
3) The managed bindings for the products in 2). Some of these we maintain ourselves (in the component store - Crittercism ), some are maintained by those companies themselves (HockeyApp ), and some I believe are community supported/written.
5) The app (developer).
Ideally whatever we come up with should require changes from as few of these as possible, the best case scenario being #3 only (besides ourselves of course). Any changes to #1 will likely require changes to #2 as well.
Sent from Outlook<http://aka.ms/weboutlook>
From: Rodrigo Kumpera
Sent: Monday, September 19, 2016 8:51:02 PM
To: Rolf Kvinge
Cc: Miguel de Icaza; macios-devel at lists.dot.net; mono-devel-list at lists.dot.net; android-devel at lists.dot.net
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters
On your suggestion, I'm not sure that's exactly what we want.
Even though we can ask user to do signal chaining themselves, I don't think it's necessary. I don't think we should be promoting the broken design of posix signals around. ;)
Another thing is that this design is not portable and exposes a bit too much of mono internals.
What about this: https://gist.github.com/569e860dd7e73bde0d8d098f95143662
It probably won't compile as I normalized the signature of mono_handle_native_sigsegv with other similar functions.
On 9/19/16, 3:25 AM, "Rolf Kvinge" <Rolf.Kvinge at microsoft.com> wrote:
> From: Rodrigo Kumpera
> Hey guys,
> Exposing signal handlers from managed code is always the wrong solution.
> If we're crashing in the runtime, a managed code signal handler has very little chance of works. It's a scenario we will never even consider supporting.
This is not about exposing signal handlers to managed code, the signal handlers we want called are always in native code.
> I guess the simple solution is to add an embedding API call that queues signal handlers
> to be called first before chaining to the OS one.
Something like this: https://gist.github.com/rolfbjarne/6aab59c1609f33402d195f9c34e9f99b?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the android-devel