[SR-11564] Swift 5.1.1 Regression: Bad access on generic types exported symbols – device only.

[tcldr]

Previous ID	SR-11564
Radar	rdar://problem/55987395
Original Reporter	@tcldr
Type	Bug

Attachment: Download

Environment

DEVICE AND DEVICE SIM ONLY

iOS 13.2 beta 2 and Xcode 11.2 beta 2. macOS Catalina (19A583)

Additional Detail from JIRA

Votes	55
Component/s	Compiler
Labels	Bug, 5.1Regression, RunTimeCrash
Assignee	None
Priority	Medium

md5: 04e37cf1c97866cec56b34ddb716aad1

is duplicated by:

• SR-11749 Crash only on iOS when setting subscript for non-final class in other SwiftPM module

Issue Description:

Hi,

I'm running iOS 13.2 beta 2 and Xcode 11.2 beta 2.

It appears that – when running on device or device simulator – some generic types module symbols aren't being exported.

For example: When testing the following class as part of a SPM project:

public class SomeThing<T> {
    
    private var thing: T?
    
    public init() {}
    
    public func doThing() {
        print("the thing")
    }
}

With the following test:

import XCTest
import SPMTestCrash

final class SPMTestCrashTests: XCTestCase {
    func testExample() {
        let someThing = SomeThing<Int>()
        someThing.doThing() // <-- crashes here
    }

    static var allTests = [
        ("testExample", testExample),
    ]
}

I'm getting a bad access error.

Although I've used an SPM project as an example, I believe it's occurring with any module export. (I'm seeing other similar bad access crashes in other code.)

In fact, you can see with the example above (and SPM project attached) that I'm not using the `@testable` attribute to import the module for the test – I've just made the relevant API in the test class public. (Though, it also crashes with the default access modifiers and using the `@testable` attribute.)

[belkadan]

Double-checking: that "iOS 10.2" should be "13.2" as in the Environment field, right?

@swift-ci create

[tcldr]

Yes, iOS 13.2b1!

My third edit to correct version numbers. I think they're all finally correct now... 🙂

[eeckstein]

Can you try with Xcode 11.1 (11A1027)?
I could not reproduce the problem with this Xcode. It could be a bug which is already fixed.

[tcldr]

Hi Erik – it doesn't happen with Xcode 11.1 (11A1027). But it does with Xcode 11.2 beta (11B41).

[eeckstein]

Thanks for trying!
So I think this can be closed then

[tcldr]

So is the Xcode 11.2 beta using a version of Swift which doesn't contain fixes from Xcode 11.1?

[eeckstein]

Ah, sorry. I misread the version number. Disregard my last comment

[tcldr]

Updated to reflect that issue is still outstanding on iOS 13.2 beta 2 and Xcode 11.2 beta 2.

[swift-ci]

Comment by Randy R (JIRA)

Still happening with Xcode 11.2 final.

[tcldr]

For me also, @jckarter mentioned it may be a linker bug, and to try whole module optimisation, but I don't think that's solved it for me!

[swift-ci]

Comment by Ilya Mikhaltsou (JIRA)

Is there any estimate for the resolution of this problem? This is blocking us from updating to latest Xcode version

[tcldr]

In the context of the example above, it turns out that using the 'Release' configuration (Edit scheme... > Test > Build Configuration: Release) will prevent a runtime crash – at least in this contrived example.

However, that prevents a module from being tested via the "@testable" attribute, and when enabling 'release' configuration in the 'run' mode on my current project where I initially identified the issue, it unfortunately seemed only to move the runtime crash elsewhere.

Now I crash with:

{code: none}
#0 0x00000001b6f9d8e0 in __abort ()
#1 0x00000001b6f9d850 in abort ()
#2 0x00000001c482efcc in swift_runtime_unreachable(char const*) ()
#3 0x00000001c4830c24 in swift_getAssociatedConformanceWitnessSlow ()
#4 0x00000001c483059c in swift_getWitnessTable ()
#5 0x00000001025189d4 in lazy protocol witness table accessor for type <SomeStruct> and conformance <SomeStruct> [inlined] ()

[swift-ci]

Comment by Ilya Mikhaltsou (JIRA)

Just got an interesting case. When an app built with Xcode 11.1 (with bitcode enabled) goes to TestFlight — it starts to get the same problem

[swift-ci]

Comment by Eric (JIRA)

This has completely broken our project. Debug mode will runtime crash on import, and Release mode will runtime crash when an imported 3rd party library's items are accessed. In our case RxSwift via SPM. I've tested Debug (debug executible), Release (debug executable), and Release (non-debug executale) to no avail. Any suggested workarounds? Xcode 11.2 final, Catalina 10.15.1, iOS 13.2

[swift-ci]

Comment by Randy R (JIRA)

We found a workaround.

Setting DEAD_CODE_STRIPPING = NO in our app’s target fixes the crash.