[Mono-osx] App crashes at mono_jit_exec when launched from Xcode

Fri Nov 6 21:42:16 UTC 2015

You may not be out of the woods yet.  

We build our own 64 bit Mono framework.  I also saw that patch and built both 4.0.2.x and 4.0.4.x 64 bit binaries of Mono.framework with the patch.  Sure enough, our app no longer crashed at start up.  However, I discovered a different issue when debugging one of our own problems.  If I single stepped through our program and hovered over a variable to see it’s value (Xcode shows the value in a popup bubble), then *Xcode* immediately crashed.

I backed out that patch and the Xcode crash went away.

This is worrisome. In the patched code, Mono is determining offsets into the pthread private data structures and presumably writing into those structures.  Looks like something else is going awry in this implementation.

Marlin Prowell
Robert McNeel & Associates

> On Nov 5, 2015, at 2:34 PM, Dave Burnard <dburnard at adobe.com> wrote:
> 
> For us, This has been fixed by Xamarin in v4.0.4.4 of the MonoSDK. There is a comment in the mono source that says
> "* Apple now loads a different version of pthread_getspecific when launched from Xcode"  and they look for a different sequence of instructions. Eww... 
> 
> Now back to debugging, yay!
> 
> DaveB
> 
>> On Oct 30, 2015, at 12:48 PM, Dave Burnard <dburnard at adobe.com <mailto:dburnard at adobe.com>> wrote:
>> 
>> FWIW: Here's what we see with our ElCap crash:
>> 
>> Here's what I see in Xcode's (6.X OR 7.0) lldb window using mono 4.0.4 (using mono4.2.1 shows similar results):
>> 
>> (lldb) monobt
>> * thread #1
>>     frame #0: 0x121d8653d (wrapper managed-to-native) object:__icall_wrapper_mono_object_new_fast (intptr) + 0x7d (0x121d864c0 0x121d8654e) [0x11a036840 - .]
>>   * frame #1: 0x0000000107e881e9 libmonosgen-2.0.1.dylib`mono_jit_runtime_invoke(method=<unavailable>, obj=0x0000000000000000, params=0x0000000000000000, exc=0x000000011a977968) + 1641 at mini.c:6683
>>     frame #2: 0x000000010803596e libmonosgen-2.0.1.dylib`mono_runtime_invoke(method=0x000000011a931e38, obj=0x0000000000000000, params=0x0000000000000000, exc=0x00007fff5fbfe860) + 110 at object.c:2862
>>     frame #3: 0x0000000108035e6e libmonosgen-2.0.1.dylib`mono_runtime_class_init_full(vtable=0x000000011a977838, raise_exception=0) + 798 at object.c:384
>>     frame #4: 0x0000000107e856b5 libmonosgen-2.0.1.dylib`mono_jit_compile_method_with_opt [inlined] mono_jit_compile_method_inner(method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, method=0x000000011a72d7b0, opt=<unavailable>) + 994 at mini.c:6164
>>     frame #5: 0x0000000107e852d3 libmonosgen-2.0.1.dylib`mono_jit_compile_method_with_opt(method=<unavailable>, opt=<unavailable>, ex=0x00007fff5fbfeb98) + 2851 at mini.c:6244
>>     frame #6: 0x0000000107e87cfa libmonosgen-2.0.1.dylib`mono_jit_runtime_invoke(method=0x000000011a72d7b0, obj=0x0000000000000000, params=0x00007fff5fbfee38, exc=0x0000000000000000) + 378 at mini.c:6519
>>     frame #7: 0x000000010803596e libmonosgen-2.0.1.dylib`mono_runtime_invoke(method=0x000000011a72d7b0, obj=0x0000000000000000, params=0x00007fff5fbfee38, exc=0x0000000000000000) + 110 at object.c:2862
>>     frame #8: 0x000000010803b138 libmonosgen-2.0.1.dylib`mono_runtime_exec_main(method=0x000000011a72d7b0, args=<unavailable>, exc=0x0000000000000000) + 376 at object.c:4119
>>     frame #9: 0x00000001000acff2 MyApp`DotNet::Init(runtimeVersion=0x0000000100c19c64) + 674 at DotNetMac.cpp:87
>>     frame #10: 0x000000010002e591 MyApp `MyApp::PostInitApplication(this=0x00007fff5fbff4c8, appInitArgs=0x00007fff5fbff628) + 2577 at MyApp.cpp:472
>>     frame #11: 0x000000010002d9a4 MyApp `MyApp::InitApplication(this=0x00007fff5fbff4c8, appInitArgs=0x00007fff5fbff628) + 164 at MyApp.cpp:427
>>     frame #12: 0x0000000106549c7d MyApp `AppBase::Initialize(this=0x00007fff5fbff4c8, inAppInitArgs=0x00007fff5fbff628) + 2221 at AppBase.cpp:248
>>     frame #13: 0x000000010000272c MyApp `RunApp() + 428 at MyApp.cpp:51
>>     frame #14: 0x0000000100002513 MyApp `main(argc=3, argv=0x00007fff5fbff6c0) + 51 at Muse.cpp:70
>>     frame #15: 0x00007fff85a8f5ad libdyld.dylib`start + 1
>> 
>> 
>> <Screen Shot 2015-10-05 at 11.47.17 AM.png>
>> 
>>> On Oct 6, 2015, at 11:49 AM, Adrian McCague <amccague at gmail.com <mailto:amccague at gmail.com>> wrote:
>>> 
>>> I have a similar issue as well, I did not observe this with OSX 10.10
>>> (all flavours), OSX 10.11 Beta 1 or 2 (can't remember which I upgraded
>>> from). Now seeing this in the final release of El Capitan.
>>> 
>>> I am not using mono_jit_exec but instead mono_runtime_invoke to invoke
>>> a class constructor in a DLL assembly. The LLVM debugger in XCode is
>>> hitting an EXC_BAD_ACCESS (even for an empty constructor), which is
>>> usually seen together with a NullReferenceException for obvious reasons.
>>> 
>>> Upon detaching the debugger and allowing Mono to continue execution,
>>> this is output to the console:
>>> 
>>>> Unhandled Exception:
>>>> Nested exception detected.
>>>> Original Exception: at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) <0x00086>
>>>> at System.TypeInitializationException..ctor (string,System.Exception) <0x00033>
>>>> 
>>>> Nested exception:at (wrapper managed-to-native) System.RuntimeType.getFullName (System.RuntimeType,bool,bool) <0x00094>
>>>> at System.RuntimeType.ToString () <0x00018>
>>>> at System.Exception.get_ClassName () <0x00027>
>>>> at System.Exception.ToString () <0x0001c>
>>>> 
>>>> [ERROR] FATAL UNHANDLED EXCEPTION: Nested exception detected.
>>>> Original Exception: at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) <0x00086>
>>>> at System.TypeInitializationException..ctor (string,System.Exception) <0x00033>
>>>> 
>>>> Nested exception:at (wrapper managed-to-native) System.RuntimeType.getFullName (System.RuntimeType,bool,bool) <0x00094>
>>>> at System.RuntimeType.ToString () <0x00018>
>>>> at System.Exception.get_ClassName () <0x00027>
>>>> at System.Exception.ToString () <0x0001c>
>>> 
>>> Execution is fine using the same build but without attaching the
>>> debugger. It is safe to attach the debugger after mono_runtime_invoke
>>> has been called.
>>> 
>>> Have tried with both Mono 4.2.0 and 4.2.1
>>> _______________________________________________
>>> Mono-osx mailing list
>>> Mono-osx at lists.ximian.com <mailto:Mono-osx at lists.ximian.com>
>>> http://lists.ximian.com/mailman/listinfo/mono-osx <http://lists.ximian.com/mailman/listinfo/mono-osx>
>> 
> 
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-osx/attachments/20151106/747ccdf0/attachment-0001.html>