Strange issue with XCode 14, native library & C++ exceptions

[projectgoav]

When running our app that's linked to a native C++ library, any exception thrown by that library causes the application to terminate with libstdc++:abi terminated due to uncaught exception <library type> when deployed to device.

This particular library is developed by us, has not been changed for many months and makes use of exceptions for control flow.

Issue first started to occur with the upgrade to XCode 14. It only happens when deploying to physical devices (iOS 12 -> 16). Simulators are not effected.

Everything below was tested on Visual Studio Mac 2022 v17.3.8 (Build 5) (Run on both an Intel and M1 powered Mac)

XCode 13.4.1 / Xamarin iOS 15.10.0.5 => Application runs as expected
XCode 14.0.1 / Xamarin iOS 15.10.0.5 => Application crashes due to uncaught exception
XCode 14.0.1 / Xamarin iOS 16.0.0.72 => Application crashes due to uncaught exception
XCode 14.1.0 / Xamarin iOS 16.0.0.72 => Application crashes due to uncaught exception

The following occurs when our library was built with XCode 9 & XCode 14.

If our library is built in DEBUG mode (-g -O0) the problem does not occur
If our library is built in RELEASE mode with either -O0 or -O1, the problem does not occur
If our library is built in RELEASE mode with either -O2 or -O3 the problem occurs.

When the problem occurs, and based on my rudimentary understanding, it's almost as when the exception is thrown, it fails to unwind the stack to the appropriate catch block and ends up treating it as unhandled.

Are you aware of anything that has changed with the introduction to XCode 14 and linking native code to Xamarin.iOS applications?

As our project it quite large, I am in the process of trying to obtain a small reprodicable example. If it is to do with how optmisations are applied, I might not be able to achieve that.

[rolfbjarne]

This sounds interesting... a couple of ideas:

1. You don't have to minimize the native library, only the C# code. And we'll even work with a big project as long as you can give us instructions that makes it quick and easy to reproduce.
2. Have you tried creating a sample project in Xcode that uses the native library and makes it throw exceptions? If that has the same behavior, you'll know the problem isn't with Xamarin.iOS.

[rolfbjarne]

Are you aware of anything that has changed with the introduction to XCode 14 and linking native code to Xamarin.iOS applications?

And to answer your question: no, nobody else has reported anything similar to us, and I can't remember reading about anything like this either elsewhere.

Hi @projectgoav. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[projectgoav]

Having taken your suggestions, I now have the following setup:

XCode 14, ObjC app that calls the native code => Runs as expected
.NET port of the above app => Crashes in the same way as outlined in the original example (when built with XCode 14).

I'll package up my sample projects and sent them your way. I do have a couple of questions regarding that:

• I suspect I'll hit the upload limit for GH. Is there a perfered method for sending larger files?
• Our native library allows us to talk to UPnP enabled devices. You'll need a least one on the network for our library to kick in. I can provide a sample UPnP app for this case. What is the preferred platform for that (Windows, Mac and/or Linux?)

[rolfbjarne]

• I suspect I'll hit the upload limit for GH. Is there a perfered method for sending larger files?

Whichever file-sharing service you're comfortable with (such as Dropbox).

• I can provide a sample UPnP app for this case. What is the preferred platform for that (Windows, Mac and/or Linux?)

Mac would be best, since we develop on Macs.

[projectgoav]

Share link

If you are asked for a password: Xamarin

Should contain everything you need:

• ObjC/XCode project
• .NET/VS project
• TestMediaPlayer (Sample UPnP app with suitable script to run)
• A couple of versions of our native library built with different configurations (Shows that problem only occurs with certain optmisation levels)
• Copy of the log message I see when our app crashes.

I've included a couple of README files where appropriate.

Our native library is also open source. Should it help, it can be found here (Github openhome/ohnet)

[rolfbjarne]

It seems your app requires the multicast entitlement (com.apple.developer.networking.multicast), and unfortunately that entitlement requires permission from Apple before I can use it (https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_networking_multicast?language=objc, https://developer.apple.com/contact/request/networking-multicast).

Is there any way you can simplify your app so that it doesn't require the multicast entitlement in order to reproduce the problem? Since you seem to have control over the native library, maybe just add a simple function that throws and catches an exception, and call that from C#?

Something like:

try {
    throw new SomeException ();
} catch (SomeException e) {
    // ignore
}

[projectgoav]

Hmm, I was under the impression that that entitlement worked in debug apps you just couldn't submit to the store without prior approval. It's odd, because I didn't have to specify it in the native ObjC/XCode project, it was added automatically for me.

I'll see what I can do and get back to you!

[projectgoav]

I've updated the folder at the previously shared link with an ObjC, .NET & builds of our native library that don't require the multicast entitlement. (They have a -NoMulticast post-fix on the name)

This has the same behaviour as before:
ObjC: Works with both XCode 13 & XCode 14
.NET: Works with XCode13, crashes on XCode 14 (when native library is compiled with -O2)

Interestingly, a method like you suggested does not cause the issue.

try {
    throw new XmlError();
}
catch (XmlError&) {
    // Reached!
}

However, when I call a function that throws the XmlError:

try {
    FuncThatThrowsXmlError();
}
catch (XmlError&) {
    // Not Reached!!
}

At the moment FuncThatThrowsXmlError() is quite long winded. I'll see if I can reduce that further as well.

[projectgoav]

I think this might be something to do with loop unrolling.

FuncThatThrows() looks a bit like this:

void Baz()
{
    for(;;) {
        // Do some work
        if (somethingWentWrong) {
            throw new exception;
        }
    }
}

void Bar()
{
    for(;;) {
        Baz();
        // Do some more work
        if (somethingWentWrong) {
            throw new exception;
        }
    }
}

void Foo()
{
    for(;;) {
        Bar();
        // Do even more work
        if (somethingWentWrong) {
            throw new exception;
        }
    }
}

void FuncThatThrows()
{
    // Do some work
    try {
        return Foo();
    }
    catch(exception) {
        // Something went wrong...
    }
}

Foo(), Bar() & Baz() are parsing functions. They loop indefinately until they return something or encounter a problem and then throw.

When our library is built with -O0 and -O1 and we call FuncThatThrows() from Xamarin app, the exception is bubbled up to FuncThatThrowsXmlError() and we handle the exception.

When our library is built with -O2 or -O3 and we call FuncThatThrows() from Xamarin app, the exception remains unhandled.
I assume that these optmisation levels are more aggressive at loop unrolling. Something is going wrong with that process and failing to plumb in the exception handlers?

If we run the ObjC app linked against our native library with any optimisation applied, FuncThatThrows() handles the exception and the app runs happily.

I've then attempted to change our Foo, Bar, and Baz functions to look something like:

void Foo()
{
    bool error = false;
    for(;;) {
        Bar();
        // Do some more work
        if (somethingWentWrong) {
            error = true;
            break;
        }
    }

    if (error) {
        throw new exception;
    }
}

This does not fix the issue.

I have attempted to try and disable loop unrolling via clang compiler directive #pragma clan loop unroll(disable). This did not fix the issue.

I then attempted to explicitly catch the exception in Foo() & Bar() and then rethrow.

void Foo()
{
    for(;;) {
        try {
            Bar();
        }
        catch(exception) {
            throw;
        }
        // Do some more work
        if (somethingWentWrong) {
            throw new exception
        }
    }
}

With this change in place, FuncThatThrows() successfully handles the exception.

Hope this is helpful and not just me whaffling on a bit!!

[rolfbjarne]

Thanks for the test case!

I figured it out, it happens because we pass -no_compact_unwind to the native linker. Adding this flag to the Xcode project makes the Xcode project crash the same way.

It may be possible to work around this by passing -Wl,-no_compact_unwind to the linker when building the native library.

Ref: c05e774