AppStore submissions crashing after upgrade.. how to downgrade Xamarin.Mac / Mono?

KeithBoyntonKeithBoynton GBMember ✭✭✭

My latest AppStore submissions are getting rejected due to crashes at startup and I need to downgrade to isolate what is causing the crash.

My distribution build is working just fine but each AppStore submission is getting rejected due to a crash at startup. I can't see any obvious app code changes which could cause any crashes but I've just reverted all code changes to the last successful submission and resubmitted to eliminate any app code changes as a cause.

My next test will be to downgrade the framework versions to the last successfully submitted version and resubmit to see if it's something in there that is now causing the crash.

My latest successful submission was on 3rd October 2019 so I need to downgrade to Xamarin.Mac 6.2.0.42

However, I'm struggling to find how to downgrade....

1) Where can I find the Xamarin.Mac 6.2.0.42 package?
2) It doesn't look like the Mono Framework MDK was updated since 3rd October, is that right?
3) It also looks like I need to downgrade Xcode from 11.1 to 11.0 is that necessary if I'm downgrading Xamarin.Mac?

Answers

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai
    1. If you ask support (or on the forum), someone will tend to provide a URL for a given build for downgrading:

    https://download.visualstudio.microsoft.com/download/pr/54b422d1-7448-4c23-a8dd-f6db04641531/b83dc3119d4c49f3922ff286128b4874/xamarin.mac-6.2.0.42.pkg

    1. The latest Mono is 6.4.0.208

    2. Latest "stable" release should have Xcode 11.1 support built in.

    Without additional details (or a crash log), no one will be able to help you sort out your crash, but that should be enough to get started.

  • KeithBoyntonKeithBoynton GBMember ✭✭✭

    Thank you Chris for your quick response as always...

    I don't think I was very clear with my post regarding Mono and Xcode.. I was asking whether I needed to downgrade those too so my build is in the same state as the last successful submission I made on 3rd October.

    Recently I've been updating from Stable as soon as releases come out so....

    1) If Mono has been updated since 3rd October (which I don't "think" it has from my research) then I'd need to downgrade that too. Can you confirm if it has or hasn't?
    2) If Xcode has been updated since 3rd October (which I believe it has) then I'd need to downgrade that too. I believe I do need to downgrade that.

    My latest submission got rejected too for crashing, I'd reverted the code changes to last successfully submitted version. So I now plan to downgrade Xamarin.Mac and Xcode then resubmit. I'll also downgrade Mono if you confirm it has been updated since October 3rd.

    Once I get the results of that then I can start sharing crash logs with supporting information.

  • JohnConnersJohnConners GBMember ✭✭

    Just to say when I updated from Xamarin.Mac 6.2 to 6.4 the other week it did not update Mono. I specifically remember because I was surprised as normally it would include a new version of Mono in the downloads.

  • KeithBoyntonKeithBoynton GBMember ✭✭✭

    Thanks for that @JohnConners that was my recollection too

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    6.4.0.208 is the current mono stable, and was released there on 2019-10-07. 6.4.0.198 was there since 2019-09-23.

    To be honest though, unless you are using the "system" target framework, such a minor mono bump is very unlikely to be the source of your trouble.

  • KeithBoyntonKeithBoynton GBMember ✭✭✭

    Thanks Chris... no I'm using Modern

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    It is possible that bumping mono introduced a compiler or msbuild bug, but I'd run down other angles first. Those are rather rare events.

  • KeithBoyntonKeithBoynton GBMember ✭✭✭

    Ok so here's an update so far...

    First, I downgraded everything to the setup for the last successfully submitted version. Xcode back to 11.0 Xamarin.Mac back to 6.2.0.42 but I didn't downgrade Mono from 6.4.0.208 to 6.4.0.198. It got rejected with the same crash.

    An interesting thing to note between the two Xamarin.Mac versions is that it looks like the newer version has the 32bit code stripped out now whereas the previous version didn't. I had two custom build actions to call lipo to strip out the 32bit code otherwise the AppStore rejected the binaries.

    libMonoPosixHelper.dylib -remove i386
    libmono-native.dylib -remove i386
    

    With the most recent Xamarin.Mac those commands fail because it reports there is nothing to strip (or something similar).

    Then, I brought everything back up to the most recent and changed a couple of the AppStore build configurations:

    • Changed Link Mode from Full to SdkOnly
    • Removed a load of --linkskip parameters from the MMP options

    From memory those options were there because of this historical problem, which to be honest I never fully understood
    https://forums.xamarin.com/discussion/124978/build-problem-failed-to-resolve-system-diagnostics-performancecounter

    It built successfully I submitted it and it got rejected again with the same looking crash log.

    Process:               MyApp [13224]
    Path:                  /Applications/MyApp.app/Contents/MacOS/MyApp
    Identifier:            com.flare.MyApp
    Version:               1.27.6 (5.0.62)
    App Item ID:           0
    App External ID:       0
    Code Type:             X86-64 (Native)
    Parent Process:        ??? [1]
    Responsible:           MyApp [13224]
    User ID:               502
    
    Date/Time:             2019-10-24 13:59:15.317 -0700
    OS Version:            Mac OS X 10.15 (19A602)
    Report Version:        12
    Anonymous UUID:        F814D616-4D57-037F-BBBD-E0B955A63D07
    
    Sleep/Wake UUID:       1F9CAB84-62C2-434E-8179-F0122319E466
    
    Time Awake Since Boot: 77000 seconds
    Time Since Wake:       66000 seconds
    
    System Integrity Protection: enabled
    
    Crashed Thread:        0  tid_307  Dispatch queue: com.apple.main-thread
    
    Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
    Exception Note:        EXC_CORPSE_NOTIFY
    
    Termination Signal:    Segmentation fault: 11
    Termination Reason:    Namespace SIGNAL, Code 0xb
    Terminating Process:   exc handler [13224]
    
    VM Regions Near 0:
    --> 
        __TEXT                 000000010c691000-000000010ca99000 [ 4128K] r-x/r-x SM=COW  /Applications/MyApp.app/Contents/MacOS/MyApp
    
    Thread 0 Crashed:: tid_307  Dispatch queue: com.apple.main-thread
    0   com.flare.MyApp             0x000000010c9a517d eglib_log_adapter + 13
    1   com.flare.MyApp             0x000000010c9bfb05 monoeg_g_logv_nofree + 181
    2   com.flare.MyApp             0x000000010c9bfc8f monoeg_assertion_message + 143
    3   com.flare.MyApp             0x000000010c785d79 mono_jit_thread_attach + 169
    4   com.flare.MyApp             0x000000010c6971a0 xamarin_switch_gchandle + 144
    5   com.flare.MyApp             0x000000010c69a227 xamarin_release_trampoline + 103
    6   libobjc.A.dylib                 0x00007fff7152f53a AutoreleasePoolPage::releaseUntil(objc_object**) + 134
    7   libobjc.A.dylib                 0x00007fff71515c70 objc_autoreleasePoolPop + 175
    8   com.flare.MyApp             0x000000010c6a232b xamarin_main + 1211
    9   com.flare.MyApp             0x000000010c6a3144 main + 36
    10  libdyld.dylib                   0x00007fff7287e405 start + 1
    
    Thread 1:
    0   libsystem_pthread.dylib         0x00007fff72a875b4 start_wqthread + 0
    
    Thread 2:
    0   libsystem_pthread.dylib         0x00007fff72a875b4 start_wqthread + 0
    
    Thread 3:
    0   libsystem_pthread.dylib         0x00007fff72a875b4 start_wqthread + 0
    
    Thread 4:
    0   libsystem_pthread.dylib         0x00007fff72a875b4 start_wqthread + 0
    
    Thread 0 crashed with X86 Thread State (64-bit):
      rax: 0x000000010c9a5170  rbx: 0x0000000000000000  rcx: 0x0000000000000004  rdx: 0x00007fdca942a070
      rdi: 0x0000000000000000  rsi: 0x0000000000000004  rbp: 0x00007ffee356e4c0  rsp: 0x00007ffee356e4c0
       r8: 0x0000000000000000   r9: 0x00000000000007fb  r10: 0x0000000000000004  r11: 0x00007fdb9ca3915a
      r12: 0x0000000000000000  r13: 0x0000000000000000  r14: 0x0000000000000004  r15: 0xa3a3a3a3a3a3a3a3
      rip: 0x000000010c9a517d  rfl: 0x0000000000010202  cr2: 0x0000000000000000
    
    Logical CPU:     2
    Error Code:      0x00000004 (no mapping for user data write)
    Trap Number:     14
    

    I did Symbolicate one of the crash logs and it looked like this:

    Thread 0 Crashed:: tid_307  Dispatch queue: com.apple.main-thread
    0   com.flare.MyApp             0x000000010f97821d eglib_log_adapter (in MyApp) (mono-logger.c:404)
    1   com.flare.MyApp             0x000000010f992ba5 monoeg_g_logv_nofree (in MyApp) (goutput.c:150)
    2   com.flare.MyApp             0x000000010f992d2f monoeg_assertion_message (in MyApp) (goutput.c:184)
    3   com.flare.MyApp             0x000000010f758e19 mono_jit_thread_attach (in MyApp)
    4   com.flare.MyApp             0x000000010f66a240 xamarin_switch_gchandle (in MyApp) (runtime.m:1853)
    5   com.flare.MyApp             0x000000010f66d2c7 xamarin_release_trampoline (in MyApp) (trampolines.m:637)
    6   libobjc.A.dylib                 0x000000011617a4ea AutoreleasePoolPage::releaseUntil(objc_object**) + 134
    7   libobjc.A.dylib                 0x0000000116160440 objc_autoreleasePoolPop + 175
    8   com.flare.MyApp             0x000000010f6753cb xamarin_main (in MyApp) (launcher.m:674)
    9   com.flare.MyApp             0x000000010f6761e4 main (in MyApp) (launcher.m:679)
    10  libdyld.dylib                   0x00000001163582e5 start + 1
    

    Which didn't really help me... maybe you've seen something here that looks familiar?

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    Hi @ChrisHamons and @JohnConners, I'm looking at this a bit with @KeithBoynton and it's one of those issues that is really hard to troubleshoot. It runs fine when building locally in the Release and when signed for direct Distribution, it's only when built for the App Store configuration where it is signed with different provisioning that the problem happens. But I'm not sure of a way to run an app store build locally to test it due to security constraints - unless there is a way to do that? I'd be glad to learn...

  • JohnConnersJohnConners GBMember ✭✭

    So the way I test App Store builds is to do the build exactly as I'd submit it to Apple then drop the app in my Applications folder (and apologies if I'm telling you things you already know). When you launch it macOS will apply the sandbox and if you do MAS receipt checking (and so return with code 173 if there is no valid receipt) then macOS will launch an app store login dialog. This is actually for the sandbox app store so you'll need to create a user here:

    https://appstoreconnect.apple.com/access/testers

    Then it'll apply the receipt and relaunch. At this point it's basically running in the same way Apple will be testing it and once it's downloaded from the App Store - so sandbox applied and MAS receipt attached. I would ideally expect it to crash the same way Apple are seeing at this point.

    Now if it doesn't crash then the "nuke it from space" option is to install macOS in a Virtual Machine that doesn't have anything installed (i.e. Mono / Xamarin.Mac / etc) and drop it in Applications there and see what happens. That would eliminate something being locally installed allowing it to run.

    Couple of other things spring to mind. What version of macOS are you testing on? Is the direct distribution version sandboxed? And is the app (direct and MAS builds) using the hardened runtime?

  • KeithBoyntonKeithBoynton GBMember ✭✭✭

    Thanks @JohnConners that's a technique I certainly wasn't aware of, really helpful thank you!

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    Agreed! Thank you.

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    libMonoPosixHelper.dylib -remove i386
    libmono-native.dylib -remove i386

    With the most recent Xamarin.Mac those commands fail because it reports there is nothing to strip (or something similar).

    Yep - we fixed that a number of versions ago. :)

    I would consider AOT'ing your application, or at least your main exe and see if you get a more reasonable stack trace.

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    @JohnConners Just getting back to this... When you say "if you do MAS receipt checking" I'm actually not sure I've ever done that specifically from within an app. Do you have any more specific about that?

  • JohnConnersJohnConners GBMember ✭✭
    edited November 6

    Yes @DennisWelu so I use something similar to this to check the MAS receipt when the app launches in app store mode:

    https://github.com/pmhart83/xamarin-mac-RVNReceiptValidation-binding

    If you find that IsValidAppStoreReceipt() returns false then calling Environment.Exit( 173 ); will tell macOS to go and ask the MAS for user verification on first run. Note that the MAS login dialog functionality will only work if the app is running in Applications I believe.

    Of course you don't need to do this as the sandbox should still be applied when running in Applications.

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭
    Awesome thanks much!
  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    @JohnConners @ChrisHamons Does anyone happen to have a copy of the RVNReceiptValidation.dll and dylib they could zip up? The makefile no longer works at https://github.com/pmhart83/xamarin-mac-RVNReceiptValidation-binding and so far I've not had success trying to update it.

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    Or, more specifically, maybe someone knows how to fix this up to current for generating the bindings. Here's the line in the Makefile that fails:

    MONO_PATH=$(XM_PATH)/lib/mono/Xamarin.Mac $(XM_PATH)/bin/bmac-mobile-mono $(XM_PATH)/lib/bmac/bmac-mobile.exe -baselib:$(XM_PATH)/lib/reference/mobile/Xamarin.Mac.dll --api=$(BASE_FILE_NAME).cs -o:bin/$(BASE_FILE_NAME).dll --tmpdir=tmp --ns=$(NAMESPACE)

    The reference to bmac-mobile.exe is no longer valid. So I change that to use bgen.exe instead and then I get an error about a --target-framework must be specified.

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    In general these days we strongly suggest using a binding project, as it handles the invocation for you under the hood. If you aren't using that, you should really use the script:

    /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/bin/bmac

    We reduced some of our duplication between Modern and Full tools, which is affecting that invocation I think.

    Changing:

    $(XM_PATH)/lib/bmac/bmac-mobile.exe

    to

    $(XM_PATH)/lib/bmac/bmac.exe

    may fix it for you.

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    Thanks @ChrisHamons . That's what I tried to do, but then it gave an error of "--target-framework" must be specified. Does it makes sense that the additional argument should be given and thoughts on what it should be (or is that app dependent)?

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    If it is Modern, then you want:

    --target-framework=Xamarin.Mac,Version=v2.0,Profile=Mobile

    Or moving the the bmac script, which does that for you

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    That got the makefile further using this line:

    MONO_PATH=$(XM_PATH)/lib/mono/Xamarin.Mac $(XM_PATH)/bin/bmac-mobile-mono $(XM_PATH)/lib/bgen/bgen.exe --target-framework=Xamarin.Mac,Version=v2.0,Profile=Mobile -baselib:$(XM_PATH)/lib/reference/mobile/Xamarin.Mac.dll --api=$(BASE_FILE_NAME).cs -o:bin/$(BASE_FILE_NAME).dll --tmpdir=tmp --ns=$(NAMESPACE)

    One point relative to a previous comment - the EXE referenced is "bgen.exe" not "bmac.exe". I don't see a bmac.exe any more.

    I documented my question and attempt as an issue on the repository: https://github.com/pmhart83/xamarin-mac-RVNReceiptValidation-binding/issues/1

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai
    edited November 12

    Yes we removed bmac for bgen here.

    You should be able to replace any bmac for bgens references.

    As a side note, we didn't consider this a major breaking change as we ask people to use the script or binding projects for this reason :)

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    FWIW, I moved on to the next problem by removing the $(XM_PATH)/lib/bgen/bgen.exe from the makefile build line because it looks like that is already contained within the "/bin/bgen" script.

    That moves me on to the next problem which is:

    error BI0002: bgen: Could not compile the API bindings.
    Microsoft (R) Visual C# Compiler version 3.3.1-beta4-19462-11 (66a912c9)
    Copyright (C) Microsoft Corporation. All rights reserved.

    * Assertion at class-init.c:3363, condition `cur_slot == klass->vtable_size' not met

    Tried all the various versions of Xamarin.Mac.Frameworks I have available locally, all the 6.x versions have the same result. Does that given anyone ideas?

    @JohnConners if you have a copy of the output already built any chance you could zip it up? Many Internet blessings would be upon you. I'm just trying to get to the point I can debug an AppStore build. :)

  • JohnConnersJohnConners GBMember ✭✭

    So I actually created my own Xcode library project, included RVNReceiptValidation.h, RVNReceiptValidation.m and RVNReceiptValidationEx.m and a new file called LicChecker.m with the following (replace the bundle ID with your own - note that I don't bother to check the version, hence why it's commented out):

    #include <CoreFoundation/CoreFoundation.h>
    #include "RVNReceiptValidation.h"
    
    #define EXPORT __attribute__((visibility("default")))
    
    EXPORT int checkReceipt()
    {
        RVNReceiptValidation *val = [[RVNReceiptValidation alloc] init];
        /*NSString *ver = [NSString stringWithUTF8String: bundleVersion];
        [val setBundleVersion:ver];*/
        [val setBundleID:@"com.mycompany.myapp"];
        bool isValid = [val isValidAppStoreReceipt];
        if( isValid == true )
            return 1;
    
        return 0;
    }
    

    Then in C# I declare this:

    [DllImport( "nameofmyhelperlibrary.dylib" )]
    public static extern uint checkReceipt();
    

    And can just call that checkReceipt() method and test the return value. I make sure the dylib is built and signed as part of my build process (calling xcodebuild) and copied into the app's MonoBundle folder. Not as fancy as a binding dll but seems to work!

  • DennisWeluDennisWelu USUniversity, Developer Group Leader ✭✭

    Well that makes good sense! Was able to create the dylib, and it seems to be referenced, loading, and executing. Thank you for that!

    I'm on to the next problem which is when I copy the AppStore build into my Applications folder it still crashes with the Code Signature Invalid exception. I'll continue to poke at that one.

Sign In or Register to comment.