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

Discussion:

Dave Burnard

2015-09-30 15:58:36 UTC

On the ElCap GM, we're seeing that our hybrid XcodeC++/XamarinC# app will launch just fine from command line or can be launched and debugged from Xamarin. But if we launch the app from Xcode 6 (or 7) we crash trying to load our main assembly via mono_jit_exec. We can attach Xcode after initialization and then debug. Anyone else seeing this behavior?

We're on the stable channel. A bit more detail: We don't use Xamarin.Mac, we're not making any OS X API calls from our C# code (just engine code and calls to/from our native code). Late last week I downloaded mono-4.2.0.207.tar.bz2 and built and substituted those binaries into our process - but saw the same crash launching from Xcode (could see more levels on the stack, though they were greek to me).

Anyone else seeing this, or have any recommendations for fixes or workarounds?

DaveB

Rodrigo Kumpera

2015-10-05 15:29:23 UTC

Permalink

This is odd because it's how Xamarin Studio works on OSX.

Can you share a symbolificated crash log of what you're seeing?

Post by Dave Burnard
On the ElCap GM, we're seeing that our hybrid XcodeC++/XamarinC# app will
launch just fine from command line or can be launched and debugged from
Xamarin. But if we launch the app from Xcode 6 (or 7) we crash trying to
load our main assembly via mono_jit_exec. We can attach Xcode after
initialization and then debug. Anyone else seeing this behavior?
We're on the stable channel. A bit more detail: We don't use Xamarin.Mac, we're
not making any OS X API calls from our C# code (just engine code and calls
to/from our native code). Late last week I downloaded
mono-4.2.0.207.tar.bz2 and built and substituted those binaries into our
process - but saw the same crash launching from Xcode (could see more
levels on the stack, though they were greek to me).
Anyone else seeing this, or have any recommendations for fixes or workarounds?
DaveB
_______________________________________________
Mono-osx mailing list
http://lists.ximian.com/mailman/listinfo/mono-osx

Adrian McCague

2015-10-06 18:49:57 UTC

Permalink

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,

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

Marlin Prowell

2015-10-30 19:09:51 UTC

Permalink

We are also seeing this crash and have submitted a Bugzilla report with sample code that exhibits the problem: https://bugzilla.xamarin.com/show_bug.cgi?id=35416. Works fine on Yosemite, Xcode 6.4, and Mono.framework 4.0.4. Crashes with El Capitan, Xcode 7.1, and Mono.framework 4.0.4. Sample app runs fine with El Capitan and Mono.framework 4.0.4 when run from the command line. Same crash exists using Mono.framework 4.2.0.

Marlin Prowell
Robert McNeel & Associates

Post by Adrian McCague
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,

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
http://lists.ximian.com/mailman/listinfo/mono-osx

Dave Burnard

2015-10-30 19:48:09 UTC

Permalink

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

[cid:F3E2F9FC-FC96-4322-B5B4-***@corp.adobe.com]

On Oct 6, 2015, at 11:49 AM, Adrian McCague <***@gmail.com<mailto:***@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

Dave Burnard

2015-11-05 22:34:06 UTC

Permalink

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 <***@adobe.com<mailto:***@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 <***@gmail.com<mailto:***@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

Marlin Prowell

2015-11-06 21:42:16 UTC

Permalink

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

Post by Dave Burnard
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

Post by Dave Burnard
(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>

_______________________________________________
Mono-osx mailing list
http://lists.ximian.com/mailman/listinfo/mono-osx

Adrian McCague

2015-12-15 14:23:16 UTC

Permalink

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

Post by Marlin Prowell
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
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
Here's what I see in Xcode's (6.X OR 7.0) lldb window using mono 4.0.4
(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>
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,
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
http://lists.ximian.com/mailman/listinfo/mono-osx
_______________________________________________
Mono-osx mailing list
http://lists.ximian.com/mailman/listinfo/mono-osx
_______________________________________________
Mono-osx mailing list
http://lists.ximian.com/mailman/listinfo/mono-osx

--
Adrian McCague