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 <e...@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 <mig...@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.bois...@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@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
