[android-devel] [macios-devel] Signal-chaining & crash reporters

Fri Sep 23 18:01:03 UTC 2016

This looks tasty to me ☺

From: Rolf Kvinge <Rolf.Kvinge at microsoft.com>
Date: Friday, September 23, 2016 at 8:28 AM
To: Rodrigo Kumpera <rokumper at microsoft.com>, Miguel de Icaza <miguel at microsoft.com>
Cc: "macios-devel at lists.dot.net" <macios-devel at lists.dot.net>, "mono-devel-list at lists.dot.net" <mono-devel-list at lists.dot.net>, "android-devel at lists.dot.net" <android-devel at lists.dot.net>
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters

Hi,

I've tried implementing this, here's a Mono PR for it: https://github.com/mono/mono/pull/3624

I'm not where to document the new managed API though.

Rolf

Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: Rodrigo Kumpera
Sent: Thursday, September 22, 2016 11:05:07 PM
To: Miguel de Icaza; Rolf Kvinge
Cc: 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

Hey,

Given Rolf’s constraints, I don’t think we can do reasonably better than your proposal.

--
Rodrigo

From: Miguel de Icaza <miguel at microsoft.com>
Date: Tuesday, September 20, 2016 at 6:01 AM
To: Rolf Kvinge <Rolf.Kvinge at microsoft.com>, Rodrigo Kumpera <rokumper at microsoft.com>
Cc: "macios-devel at lists.dot.net" <macios-devel at lists.dot.net>, "mono-devel-list at lists.dot.net" <mono-devel-list at lists.dot.net>, "android-devel at lists.dot.net" <android-devel at lists.dot.net>
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters

Hello,

My proposal addressed that, the downside is that there is a window at startup where the runtime will not catch exceptions properly.

I think it is fair to document the limitation of the technique in those scenarios.

From: Rolf Kvinge <Rolf.Kvinge at microsoft.com>
Date: Tuesday, September 20, 2016 at 5:17 AM
To: Rodrigo Kumpera <rokumper at microsoft.com>
Cc: Miguel de Icaza <miguel at microsoft.com>, "macios-devel at lists.dot.net" <macios-devel at lists.dot.net>, "mono-devel-list at lists.dot.net" <mono-devel-list at lists.dot.net>, "android-devel at lists.dot.net" <android-devel at lists.dot.net>
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters

Hi Rodrigo,

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 [1].

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 [2]), etc.

3) The managed bindings for the products in 2). Some of these we maintain ourselves (in the component store - Crittercism [3]), some are maintained by those companies themselves (HockeyApp [4]), and some I believe are community supported/written.

4) Us.

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.

Rolf

[1] https://plcrashreporter.org<https://plcrashreporter.org/>

[2] http://stackoverflow.com/questions/14041789/comparison-between-testflight-live-quincykit-and-crashlytics#comment19667280_14103776

[3] https://components.xamarin.com/gettingstarted/crittercism

[4] https://github.com/bitstadium/HockeySDK-Xamarin

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

Hey Rolf,

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.

--
Rodrigo

On 9/19/16, 3:25 AM, "Rolf Kvinge" <Rolf.Kvinge at microsoft.com> wrote:

    Hi,

    > 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?

    Rolf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/android-devel/attachments/20160923/b647be5e/attachment-0001.html>