[Mono-dev] signal issue? crash when debugger attached and web request fails

Jonathan Mitchell lists at mugginsoft.com
Tue Feb 21 13:53:01 UTC 2017




> On 20 Feb 2017, at 16:18, Zoltan Varga <vargaz at gmail.com> wrote:
> 
> Hi,
> 
>   Where is the crash location ? The runtime implements null reference exception checking by catching the SIGSEGV signal, so if a nullref happens in managed code while running under lldb, it will look like a crash. Running with 
> MONO_DEBUG=explicit-null-checks
> turns this behavior off.
> 

Hi 

Thanks for that.

And yes using MONO_DEBUG=explicit-null-checks mitigates the issue.
I can detect when LLDB is attached and set the env var as required https://github.com/ThesaurusSoftware/Dubrovnik/commit/15b86e3e6c9381944d95488e52ecaad314a1ed81.

This issue was occurring on a background worker thread which has perhaps complicated things.
The code is cross platform and WIndows does not raise NullReferenceException at any point.
This may explain why (with LLDB detached) the WIndows error reporting has valid reason for failure detail whereas the Mono implement is empty.

I have some test code for for raising NullReferenceException that I previously used to see just how my app processes managed exceptions into Obj-C ones.
When LLDB is attached the behaviour for this test code is that LLDB does NOT catch the SIGSEGV - which i find curious:
 
scenario 1
========

methodA raises an uncaught NullReferenceException.

    monoResult = mono_runtime_invoke(methodA, NULL, monoArgs, &monoException);
    if (monoException != NULL) {
        @throw(NSExceptionFromMonoException(monoException, @{}));
    }
In this case SIGSEGV is not caught by LLDB and I see NSExceptionFromMonoException raised.

Scenario 2
========

// no monoException argument
monoResult = mono_runtime_invoke(methodA, NULL, monoArgs, NULL);

In this case the exception handler I have installed on AppDomain_UnhandledException gets called and still SIGSEGV is not caught by LLDB.

Is the fact that the NullReferenceException is occurring on a background worker thread significant?
I do have a custom System.Threading.SynchronizationContext installed to route worker thread completion code back onto the Obj-C main thread but we never get that far in this case.

J



More information about the Mono-devel-list mailing list