[Mono-dev] [SIGNAL] Segfault in native function called by managed code

[Raphael Boissel]

Hello,

To be fair there is a way to implement your own SEGFAULT handler directly in C#
(or any other language that targets .NET) by simply calling the native function
signal (or sigaction like) and passing a managed method using a native->managed
wrapper (that can be created using Marshall functions).

However, if you do so you will replace the traphandler used by mono and then
you will have to do part of its job to at least know if the segfault
should be handled
by your traphandler or by the one installed by mono. And you will
likely not have
enough data to do it correctly, like the JIT tables indicating which
portions of the
memory belongs to which JITed functions.

And I really guess nobody will recommend using such a messy solution anyway.

I don't know if there is another way to catch SEGFAULT in mono but I don't think
so. If it would be configurable then we will have a clean way to catch
the exceptions
and as you said handle it correctly:
* let the user send a bug report
* capture the stacktrace and open a bug submission form
* We can even think of the case of a testsuite where we most likely don't want
the testsuite to be interrupted for a SEGFAULT (we an of course run
each test in separate processes but it makes it less convenient)


Thanks,

-- 
Raphaël 'Shugo' Boissel


2015-09-06 23:34 GMT-07:00 Eberhard Beilharz <eb1 at sil.org>:
> Making it configurable would seem like a good option to me. Currently if the
> app gets a SEGFAULT it simply disappears for the user without leaving a
> trace, so I as a developer can't easily see what happened on the user's
> machine nor can I implement code that would give the user a chance to report
> what happened.
>
> If it would be configurable then we could catch the exception, let the user
> send in an error report, and then try to reproduce it, possibly with the
> other configuration set so that we see the SEGFAULT.
>
> Or am I missing something how the SEGFAULT could currently be handled in a
> mono app?
>
> Thanks
>     Eberhard
>
>
> Miguel De Icaza <miguel at xamarin.com> wrote on 2015-09-05 at 03:32 +0200:
>
> It is an implementation choice.
>
> Perhaps we could make this configurable, but more often than not, this
> indicates a serious issue, and surfacing something so useful as a
> AccessViolationException reduces the usefulness of the feature.
>
> On Fri, Sep 4, 2015 at 6:15 AM, Raphael Boissel <raphael.boissel at gmail.com>
> wrote:
>>
>> Hello,
>>
>>
>> I have one little question on the way mono currently handles/uses the
>> SEGFAULT signal on Unix OSes.
>>
>> Currently, and correct me if I'm wrong, either the segfault has been
>> raised by a managed function and in this case it is handled as a
>> genuine exception for instance a nullRefException or if it is triggered
>> by native code the entire program is stopped and a stacktrace is
>> displayed.
>>
>> However it seems that mono also follow the second behavior for
>> native code that has been invoked inside managed code,
>> where I would have expected an AccessViolationException.
>>
>> Is there any specific reasons why this behavior is followed, or is it
>> just an implementation choice ?
>>
>> (sorry about the potential double post I sent it first with a
>> non-whitelisted
>> e-mail address)
>>
>> Thanks,
>>
>> --
>> Raphaël 'Shugo' Boissel
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>