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.
From: Miguel de Icaza <mig...@microsoft.com>
Date: Friday, September 16, 2016 at 12:42 PM
To: Rodrigo Kumpera <rokum...@microsoft.com>
Cc: Rolf Kvinge <rolf.kvi...@microsoft.com>, "macios-de...@lists.dot.net"
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters
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
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
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.
Sent from Nylas
the extensible, open source mail client.
On Sep 16 2016, at 12:00 pm, Rolf Kvinge via android-devel
> On 16/09/16 19:22, "Miguel de Icaza"
> <mig...@microsoft.com<mailto:mig...@microsoft.com>> wrote:
> 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?
macios-devel mailing list
android-devel mailing list
Mono-devel-list mailing list