Forum Xamarin.iOS

Signed Debug Build will Build but not Open

pmhart83pmhart83 USMember ✭✭✭

Last night I was able to build / open a debug build that was signed with a provisioning profile for the Xamarin.Mac app. It works if I do not sign the build.

The console output looks like this when it crashes:

The stack trace I get looks like this:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

VM Regions Near 0:
-->
__TEXT 0000000100000000-000000010034c000 [ 3376K] r-x/rwx SM=COW /Users/USER/*/Musicnotes.app/Contents/MacOS/Musicnotes

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8cff20ae __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff9b3c1500 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff8df4537b abort + 129
3 com.musicnotes.xamarin.osx 0x00000001000eb482 mono_handle_native_sigsegv + 578 (mini-exceptions.c:2386)
4 com.musicnotes.xamarin.osx 0x000000010006086a mono_arch_handle_altstack_exception + 90 (exceptions-amd64.c:864)
5 com.musicnotes.xamarin.osx 0x00000001000fef24 mono_sigsegv_signal_handler + 436 (mini.c:6828)
6 libsystem_platform.dylib 0x00007fff92fe752a _sigtramp + 26
7 ??? 000000000000000000 0 + 0
8 libsqlite3s.dylib 0x0000000108ef3fd0 dbFindIndex + 70
9 libsqlite3s.dylib 0x0000000108ef3f38 sqlite3_key + 31
10 ??? 0x0000000108ed543c 0 + 4444738620
11 ??? 0x0000000108ed1f6b 0 + 4444725099
12 com.musicnotes.xamarin.osx 0x0000000100101549 mono_jit_runtime_invoke + 1673 (mini.c:6683)
13 com.musicnotes.xamarin.osx 0x000000010019fd6e mono_runtime_invoke + 110 (object.c:2862)
14 com.musicnotes.xamarin.osx 0x00000001001a01f5 mono_runtime_class_init_full + 677 (object.c:388)
15 com.musicnotes.xamarin.osx 0x00000001000fe7d1 mono_jit_compile_method_with_opt + 3377 (mini.c:6165)
16 com.musicnotes.xamarin.osx 0x00000001000fda5a mono_jit_compile_method + 42 (mini.c:6281)
17 com.musicnotes.xamarin.osx 0x00000001000f2cf8 common_call_trampoline + 1256 (mini-trampolines.c:590)
18 ??? 0x0000000102500172 0 + 4333764978
19 ??? 0x00000001082e0758 0 + 4432201560
20 ??? 0x00000001082e06ca 0 + 4432201418
21 com.musicnotes.xamarin.osx 0x0000000100101549 mono_jit_runtime_invoke + 1673 (mini.c:6683)
22 com.musicnotes.xamarin.osx 0x000000010019fd6e mono_runtime_invoke + 110 (object.c:2862)
23 com.musicnotes.xamarin.osx 0x00000001001a01f5 mono_runtime_class_init_full + 677 (object.c:388)
24 com.musicnotes.xamarin.osx 0x00000001000f3550 mono_class_init_trampoline + 48 (mini-trampolines.c:907)
25 ??? 0x0000000102500632 0 + 4333766194
26 ??? 0x00000001082e0275 0 + 4432200309
27 com.musicnotes.xamarin.osx 0x0000000100101549 mono_jit_runtime_invoke + 1673 (mini.c:6683)
28 com.musicnotes.xamarin.osx 0x000000010019fd6e mono_runtime_invoke + 110 (object.c:2862)
29 com.musicnotes.xamarin.osx 0x00000001000070d8 xamarin_invoke_trampoline + 4920 (trampolines-invoke.m:329)
30 com.musicnotes.xamarin.osx 0x0000000100007891 xamarin_arch_trampoline + 193 (trampolines-x86_64.m:542)
31 com.musicnotes.xamarin.osx 0x0000000100008d5a xamarin_x86_64_common_trampoline + 110 (trampolines-x86_64-asm.s:59)
32 com.apple.AppKit 0x00007fff95b0e4a1 -[NSCustomObject nibInstantiate] + 346
33 com.apple.AppKit 0x00007fff95b0e2e3 -[NSIBObjectData instantiateObject:] + 309
34 com.apple.AppKit 0x00007fff95b0d967 -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] + 428
35 com.apple.AppKit 0x00007fff95b04bc5 loadNib + 384
36 com.apple.AppKit 0x00007fff95b040d5 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 300
37 com.apple.AppKit 0x00007fff95b03e9e -[NSBundle(NSNibLoading) loadNibNamed:owner:topLevelObjects:] + 201
38 com.apple.AppKit 0x00007fff95b03c6a +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 344

Posts

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    Hmm. So roughly what you stack says to me is:

    38-32 -> We're loading a nib, spinning up a NSCustomObject. Which needs to invoke into c#
    24-21 -> Looks like we need to spin up a c# class (make sense)
    17-12 -> We need to invoke some method
    9-8 -> We call into libsqlite3s.dylib
    6 -> OMG, we just crashed and grabbed the signal
    5-3 -> Mono noticed that we're hosed and realized nothing to do but shoot ourself in the head
    2 -> Call abort to do the shooting

    The fact that we appear to be dying inside libsqlite3s.dylib AND your log shows a sandbox deny for some db file makes me things that your settings for libsqulite aren't compatible w/ sandboxing.

    Could you turn signing off sandboxing to see if signed but not sandboxed works?

  • pmhart83pmhart83 USMember ✭✭✭

    @ChrisHamons

    Why would it matter if it's signed or not? It was working for me last night ... I have since cleaned the bin folder and maybe lost something that was there?

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai
    edited October 2015

    I have no clue. I'm just bisecting the possibilities. You could also try turning off sandboxing.

    It's always a great first order debugging technique when you have no clue what's wrong. :)

  • pmhart83pmhart83 USMember ✭✭✭

    I created a simple project with no SQLite3 or file system saves, here is what i now get:

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    Are you on 10.11? Can you attach the project?

  • pmhart83pmhart83 USMember ✭✭✭

    I narrowed it down to having the dylib in the MonoBundle folder. Even if I do not load the dylib in the code, the app will not open successfully until I delete it from the folder.

    Do I need to sign the dylib file?

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    I believe so. Code signing will complain and crash you if your bundle's contents don't match the signatures.

    You could look at the build output, find our code signing command, and re-run it on the bundle post copy to see if this is what is going on.

    You could also copy in the dylib before the build starts instead of a post build step.

  • pmhart83pmhart83 USMember ✭✭✭

    A few things.

    1. It has to be after the build otherwise the MonoBundle folder does not exist. You could do a swap / not clean the bin dir but it does not seem to work.

    2. I did verify this is the problem with the following command:
      Paul$ codesign --verify --deep --verbose=2 Musicnotes.app
      Musicnotes.app: a sealed resource is missing or invalid
      file modified: /Users/Paul/Code/musicnotes_smv-xamarin/MusicnotesMacReceiptTest/bin/Debug/Musicnotes.app/Contents/MonoBundle/MacUtil.dylib

    3. I am able to sign the dylib with code but it did not fix the issue: codesign -f -v -s "Mac Developer: Paul Hart (8ZHLKJJ837)" MacUtil.dylib

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    When you do anything to your bundle (add files, remove, modify) you need to re-run codesign on the entire bundle. Part of code singing is a list of all files w/ signatures.

    Yeah, you are right, it has to be post build. Without writing custom msbuild tasks, your best bet is to make a post-build rule that copies the file(s) in and re-runs codesign (maybe remove it from the base project).

    Once we get solid binding support in the project, this should hopefully be much less painful.

  • pmhart83pmhart83 USMember ✭✭✭
    edited October 2015

    I was able to come up with a solution after about 3 days of work that did not require a binding!

    I had to create native bindings to IOKit and CoreFoundation to re-create the copy_mac_address() function found on Apple's website.

    The problem I was having was comparing the GUID and getting the wrong mac in C#. IOKit returns the expected mac address!!

    I am having an issue with the playload version number not matching the build's version number however ...

Sign In or Register to comment.