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

[Rodrigo Kumpera]

Hey Rolf,

Looks good. Documentation goes into mono-project.com.

--
Rodrigo


On Fri, Sep 23, 2016 at 5:28 AM, Rolf Kvinge via Mono-devel-list <
mono-devel-list at lists.dot.net> wrote:

> 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
>
> [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
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.dot.net
> http://lists.dot.net/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/macios-devel/attachments/20160926/f83850b1/attachment.html>