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

[Rodrigo Kumpera]

Hey,

The problem is that C# code can be interrupted at any point in addition that user bugs in the install code could leave the runtime in a broken state.

I agree that having the runtime provide a callback to be called when we hard crash to be way to go.

--
Rodrigo

From: Miguel de Icaza <miguel at microsoft.com>
Date: Friday, September 16, 2016 at 12:42 PM
To: Rodrigo Kumpera <rokumper at microsoft.com>
Cc: Rolf Kvinge <Rolf.Kvinge 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

Hello,

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.

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.

Can you elaborate on that?   I do not quite follow.

I also hate the idea of having a window in which the runtime signals are unreliable.

Another option is to provide an explicit “callback” method that the runtime can invoke for the non-NulLReference exception codepath, and use this to chain to the HockeyApp support.

That is the code where on desktop we end up calling GDB and attaching, instead, we would invoke the method hook.

The downside of this approach is that we need special changes done on third party libraries to accommodate this.

Miguel.



--
Rodrigo


Sent from Nylas N1<https://link.nylas.com/link/d48tmovljcet4a9zmfuetdrqy/local-32fb72b2-e621/0?redirect=https%3A%2F%2Fnylas.com%2Fn1%3Fref%3Dn1>, the extensible, open source mail client.


On Sep 16 2016, at 12:00 pm, Rolf Kvinge via android-devel <android-devel at lists.dot.net<mailto:android-devel at lists.dot.net>> wrote:
Hi,
> On 16/09/16 19:22, "Miguel de Icaza" <miguel at microsoft.com<mailto:miguel at microsoft.com>> wrote:
>
> Hello,
>
> Thanks for getting these proposals out Rolf.
>
> I am not a fan of any of the provided options.
>
> We have two issues here: Mono is doing the right thing by supporting “chained handlers”, but many of these libraries can not chain signal handlers.
>
> Let me propose that we add a pair of methods, to undo the signal handling setup, and to restore the handling setup and surface those to managed code.
>
> The code for things like HockeyApp would become:
>
> Mono.UndoSignalHandlingSetup (); // SIGSEGV points back to original handlers
> HockeyAppInstallHandlers (); // SIGSEGV now points to HockeyApp handlers
> Mono.InstallSignalHandlers (); // SIGSEGV now points to Mono handler, that have chained capabilities
>
> The Undo/Install is necessary for the rare case of a library that can do proper chaining and might want to chain to another handler, so they would not chain back to Mono.
I think this could work.
Another advantage is that it would not require any code changes in the products, only Mono.
I can have a look at implementing (and testing) this, unless the runtime team wants to do it?
Rolf
_______________________________________________
macios-devel mailing list
macios-devel at lists.dot.net<mailto:macios-devel at lists.dot.net>
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.dot.net%2fmailman%2flistinfo%2fmacios-devel&data=02%7c01%7crokumper%40microsoft.com%7cdb0fbc77d5194f580a0708d3de63babf%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636096492348073849&sdata=W2Ib2LSRJDMd08Q6%2bfz7MRUXAw9gmpZaWQyvZxMOr8g%3d

_______________________________________________
android-devel mailing list
android-devel at lists.dot.net<mailto:android-devel at lists.dot.net>
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.dot.net%2fmailman%2flistinfo%2fandroid-devel&data=02%7c01%7crokumper%40microsoft.com%7cdb0fbc77d5194f580a0708d3de63babf%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636096492348073849&sdata=PkmNNDSW3Ec6oNM19Z%2bz3h1uq%2f9ZEZu3O6m1B3NvN2A%3d

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/macios-devel/attachments/20160919/c69f4d2c/attachment.html>