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

Dave Burnard dburnard at adobe.com
Thu Nov 5 22:34:06 UTC 2015 

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-osx/attachments/20151105/60045f85/attachment.html>

More information about the Mono-osx mailing list