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

Adrian McCague amccague at gmail.com
Tue Dec 15 14:23:16 UTC 2015 

I can confirm the fix for this is now in the stable release build 4.2.1.124

https://github.com/mono/mono/commit/70ef083e215af8ac9dfd8d1acba641743bfd1d78

Debugging appears to be back in Xcode. (Xcode 7.2, OSX 10.11.1 & OSX 10.11.2)

Adrian

On 6 November 2015 at 21:42, Marlin Prowell <marlin at mcneel.com> wrote:
> 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> 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> 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
> 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
>
>
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
>



-- 
Adrian McCague

More information about the Mono-osx mailing list