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-de...@lists.dot.net<mailto:android-de...@lists.dot.net>> wrote:

Hi,

> On 16/09/16 19:22, "Miguel de Icaza" 
> <mig...@microsoft.com<mailto:mig...@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-de...@lists.dot.net<mailto:macios-de...@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-de...@lists.dot.net<mailto:android-de...@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

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Reply via email to