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

tcldr commented 5 years ago


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 commented 5 years ago

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

@swift-ci create

tcldr commented 5 years ago

Yes, iOS 13.2b1!

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

eeckstein commented 5 years ago

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 commented 5 years ago

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

eeckstein commented 5 years ago

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

tcldr commented 5 years ago

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

eeckstein commented 5 years ago

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

tcldr commented 5 years ago

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

swift-ci commented 5 years ago

Comment by Randy R (JIRA)

Still happening with Xcode 11.2 final.

tcldr commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Comment by Randy R (JIRA)

We found a workaround.

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

swift-ci commented 5 years ago

Comment by Daniel Lindenkreuz (JIRA)

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

This workaround works for me as well.

swift-ci commented 5 years ago

Comment by Brandon Withrow (JIRA)

We are also experiencing this issue in the Lottie framework (https://github.com/airbnb/lottie-ios/issues/1066)

When the library is imported as a SPM package the build crashes, however if the package is imported with carthage, cocoapods, or even manually the issue is not present. Setting DEAD_CODE_STRIPPING = NO fixes the issue with SPM.

It seems that the generic generated classes are stripped when imported with SPM.

swift-ci commented 5 years ago

Comment by Srđan Rašić (JIRA)

ReactiveKit has been hit by this issue as well (https://github.com/DeclarativeHub/ReactiveKit/issues/233). We are experiencing projects crashing when calling various methods with EXC_BAD_ACCESS. Last call on the stack trace prints error: memory read failed for 0x1618de600).

Setting DEAD_CODE_STRIPPING = NO seems to fix the issue.

Xcode 11.2 on Mojave 10.14.6.

swift-ci commented 5 years ago

Comment by Randy R (JIRA)

This is interesting: https://github.com/DeclarativeHub/ReactiveKit/pull/234/files

The declaration order of methods might affect whether the symbols are stripped, e.g. public symbols before private symbols.

groue commented 5 years ago

Same issue here, also solved with the DEAD_CODE_STRIPPING = NO workaround : https://github.com/groue/GRDB.swift/issues/640

Likely duplicate bug: https://bugs.swift.org/browse/SR-11643

swift-ci commented 5 years ago

Comment by Willie (JIRA)

I can also confirm that the annoying work around DEAD_CODE_STRIPPING = NO did fix this terrible problem. I hope it will be fixed soon.

swift-ci commented 5 years ago

Comment by Jorge Revuelta Herrero (JIRA)

Happening with RxSwift as well, the workaround fixes it, the Xcode 11.2.1 GM does not fix the issue.

weissi commented 5 years ago

Seen in grpc-swift + swift-nio too https://github.com/apple/swift-nio/issues/1227#event-2785762786

swift-ci commented 5 years ago

Comment by Rolandas Razma (JIRA)

I believe we seeing same bug on Xcode 11.0 just it manifest bit later.

We moved RxSwift from CocoaPods to SPM and:

on Xcode 11.2 it crashes as soon as you run on device or simulator
on Xcode 11.1-11.0 it works on simulator or devices in any build (debug, release), but crashes if you submit build to TestFlight with same errors as on Xcode 11.2

DEAD_CODE_STRIPPING = NO - fixes crash on all versions

swift-ci commented 5 years ago

Comment by Ilya Mikhaltsou (JIRA)

RolandasR (JIRA User), crash after submission seems to be caused by Apple’s internal tooling. This started happening to us only after the day Xcode 11.2 was released and also turning bitcode off for the app to be submitted fixed issue for older Xcode.

swift-ci commented 4 years ago

Comment by Kyle Browning (JIRA)

Came across this issue yesterday. Using Xcode 11.2.1 GM Seed. The code below would crash on dict[String(describing: type)] = type

 // Dictionary to lookup subclass type from its name
    static let typeLookup: [String: FeedItem.Type] = {
        var dict: [String: FeedItem.Type] = [:]
        for type in supportedClasses {            
            dict[String(describing: type)] = type        
        }
       return dict
    }()

swift-ci commented 4 years ago

Comment by Tom Quist (JIRA)

Nimble is most likely also affected: https://github.com/Quick/Nimble/issues/708

swift-ci commented 4 years ago

Comment by Yunhao (JIRA)

I have the same issue when using SPM in my iOS project. The project works well in Xcode 11.0 but crashes when immigrating to Xcode 11.2.1. At the moment, set `DEAD_CODE_STRIPPING` to `No` solves this issue temporarily.

Hope next version of Xcode can fix this issue. I like SPM.

swift-ci commented 4 years ago

Comment by Igor Vasilev (JIRA)

The issue is also reproducible when the project is built under Xcode 11.1, uploaded to TestFlight with Bitcode enabled. 'DEAD_CODE_STRIPPING' seems to be fixing the problem

swift-ci commented 4 years ago

Comment by Randy R (JIRA)

On Xcode 11.3 beta without DEAD_CODE_STRIPPING=No, I can’t reproduce the issue.

swift-ci commented 4 years ago

Comment by Jorge Revuelta Herrero (JIRA)

So is this solved...?❓

weissi commented 4 years ago

I think this is also https://github.com/apple/swift-nio/issues/1294

adam-fowler commented 4 years ago

and https://github.com/swift-aws/aws-sdk-swift/issues/208

omochi commented 4 years ago

It is fixed in Xcode11.3 (11C29) release version.
Thanks to team.

swift-ci commented 4 years ago

Comment by Kyle Fox (JIRA)

We're still seeing this issue in Xcode 11.3.1 (11C505), but only on iOS 9 and iOS 10 devices. Setting DEAD_CODE_STRIPPING=No does still serve as a temporary solution.

swift-ci commented 4 years ago

Comment by Greg Jeckell (JIRA)

We're experiencing this issue in Xcode 11.3.1 (11C504) on all devices. The DEAD_CODE_STRIPPING=NO workaround fixes the issue.

swift-ci commented 4 years ago

Comment by Tigran Hambardzumyan (JIRA)

It is fixed for me in Xcode11.4.1(11E503a) release version.

sinoru commented 4 years ago

Seems like still this affects to dSYM generation.

swift-ci commented 3 years ago

Comment by vaux (JIRA)

We are still experiencing this issue in Xcode 12.2 (12B45b), on devices with iOS 9 and iOS 10. Can be avoided for Debug builds by setting: Build Active Architecture Only = Yes; but the issue will still be present on Release builds. DEAD_CODE_STRIPPING=No still serves as a workaround.

matt-curtis commented 3 years ago

Seeing this bug in Xcode 13.0 beta (13A5155e) :/

bimawa commented 2 years ago

xcode13.4

bimawa commented 2 years ago

How to set DEAD_CODE_STRIPPING=No in Pacakge.swift for dependency? Looks like its set to No by default for spm? DEAD_CODE_STRIPPING=No already set but spm dependency crashing

swiftlang / swift

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