Possible race condition when loading _XCTFailureHandler symbol

[flockoffiles]

I am experiencing a race condition when the symbol _XCTFailureHandler is being resolved with dlsym.

In most cases it works, but sometimes by the time it tries to resolve, the library that contains the symbol has already been unloaded, and the symbol is not resolved, so my app crashes.

I was wondering whether the stability could be improved, perhaps by trying the load the underlying XCTest library explicitly before calling dlsym?

If not, at least, add a guard for the result of dlsym being nil, and then just doing a runtime warning instead of crashing.

I am on MacOS Sonoma and Xcode 15 (tried with both the AppStore version and Xcode 15.1 beta).

[flockoffiles]

@stephencelis @mbrandonw

To get more or less predictable loading, I had to resort to the following helper function:

    private func loadXCTFailureHandler() -> XCTFailureHandler? {
#if targetEnvironment(simulator)
        guard let xcodeDeveloperPath = ProcessInfo.processInfo.environment["SIMULATOR_CAPABILITIES"]?.components(separatedBy: "/Platforms/").first else {
            // Cannot get the Xcode Library Developer path.
            return nil
        }
        let xcTestCorePath = "\(xcodeDeveloperPath)/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/XCTestCore.framework/XCTestCore"
        guard let handle = dlopen(xcTestCorePath, RTLD_GLOBAL),
              let symPtr = dlsym(handle, "_XCTFailureHandler") else {
            // Cannot load XCTestCore or _XCTFailureHandler is no longer present.
            return nil
        }
        
        return unsafeBitCast(symPtr, to: XCTFailureHandler.self)
#else
        // Cannot load for device (yet)
        return nil
#endif
    }

I know, it rather fragile, but that's the best I could come up with at the moment.
Perhaps, you would find some better way of loading XCTestCore explicitly instead of relying on the temporary loading of it by Apple (which is only happening for a split second during start-up and is easy to miss...).

[stephencelis]

@flockoffiles Any chance you can share a repro? Would love to fix any issue here, but would also like to be able to validate the fix and try other things.

[flockoffiles]

We have a really large code base (under NDA) consisting of multiple frameworks. I may try to attempt to re-create the problem by creating some similar setup (during the weekend), but I am not sure if that will work.
What I can say so far is that the problem occurs in the following setup:

Imagine two frameworks: Framework A (common classes) and Framework B (feature that makes use of common classes).
Framework A incorporates XCTestDynamicOverlay functionality and makes use of it in some of its types, i.e. some code inside Framework A calls XCTFail(...).

Framework B makes use of some class from Framework A, which in turn calls XCTFail() from XCTestDynamicOverlay.

Framework B has a sample app, which imports both Framework B and Framework A.
In many cases it all works fine, but from some point of time in time during development things start crashing.

XCode stops at the point of the crash, and it turns out that _XCTFailureHandler is nil. This pointer must have been resolved at a very early stage (when global constants are initialized). But probably because Framework A (that makes use of XCTestDynamicOverlay) is loaded later, the _XCTFailureHandler is no longer resolved.

When I investigated it, the first thing I did was that I created a function that only contained the resolving code.

I.e. instead of this:

private let _XCTFailureHandler = unsafeBitCast(
      dlsym(dlopen(nil, RTLD_LAZY), "_XCTFailureHandler"),
      to: XCTFailureHandler.self
    )

I replaced it with something like this:

private let _XCTFailureHandler: XCTFailureHandler = {
  let ptr = loadXCTFailureHandler()
  print(ptr)
  return unsafeBitCast(ptr, to: XCTFailureHandler.self)
}()

private func loadXCTFailureHandler() -> UnsafeMutableRawPointer? {
    return dlsym(dlopen(nil, RTLD_LAZY), "_XCTFailureHandler")
}

Even doing this already made ptr to be nil. In other words, the window of time during which the library containing the symbol _XCTFailureHandler is available, is very very short. And e.g. if you try to put the code dlsym(dlopen(nil, RTLD_LAZY), "_XCTFailureHandler") in the app delegate, that's also obviously too late.

Maybe, if the resolving code is placed in a global init of the main app (not in a framework), it will always work, but it's only a maybe - I have not checked it... Or maybe, the framework containing the global constant, must always be the first framework to be loaded, and it must be first framework to be loaded by the app, and preferably - really early... I have not checked that either.

But any way, we have some non-deterministic piece of functionality here because XCTestCore gets unloaded at some point, and I don't know how Apple decides when to unload it. Probably, if you're lucky enough to call dlsym for _XCTFailureHandler before the framework is unloaded, it won't be unloaded any more, but if you are trying to call dlsym after it was unloaded, you can't resolve the symbol any more...

I understand that this whole rant above is very non-specific, but that's the best I can produce so far without creating a neatly isolated reproduction example.