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

Raphael Boissel raphael.boissel at gmail.com
Sun Sep 6 20:32:07 UTC 2015


Hello,

I definitely have to agree on that. These stacktraces when a sigsegv is
received by the applications are extremely useful.

However it would be nice to at least have an option (runtime or compile-time)
to force it to behave like the Microsoft CLR does (i.e. in a case of native code
called by managed code throw and AccessViolationException).

Thanks,

-- 
Raphaël 'Shugo' Boissel

2015-09-05 3:32 GMT+02:00 Miguel de Icaza <miguel at xamarin.com>:
> 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
>>
>


More information about the Mono-devel-list mailing list