Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tcldr opened this issue Oct 3, 2019 · 42 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself crash Bug: A crash, i.e., an abnormal termination of software regression run-time crash Bug → crash: Swift code crashed during execution swift 5.1

Comments

@tcldr
Copy link

tcldr commented Oct 3, 2019

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
Copy link
Contributor

belkadan commented Oct 3, 2019

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

@swift-ci create

@tcldr
Copy link
Author

tcldr commented Oct 3, 2019

Yes, iOS 13.2b1!

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

@eeckstein
Copy link
Contributor

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
Copy link
Author

tcldr commented Oct 7, 2019

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

@eeckstein
Copy link
Contributor

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

@tcldr
Copy link
Author

tcldr commented Oct 7, 2019

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

@eeckstein
Copy link
Contributor

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

@tcldr
Copy link
Author

tcldr commented Oct 12, 2019

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

@swift-ci
Copy link
Contributor

Comment by Randy R (JIRA)

Still happening with Xcode 11.2 final.

@tcldr
Copy link
Author

tcldr commented Oct 31, 2019

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
Copy link
Contributor

swift-ci commented Nov 1, 2019

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
Copy link
Author

tcldr commented Nov 1, 2019

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
Copy link
Contributor

swift-ci commented Nov 1, 2019

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
Copy link
Contributor

swift-ci commented Nov 1, 2019

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
Copy link
Contributor

swift-ci commented Nov 1, 2019

Comment by Randy R (JIRA)

We found a workaround.

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

@swift-ci
Copy link
Contributor

swift-ci commented Nov 2, 2019

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
Copy link
Contributor

swift-ci commented Nov 4, 2019

Comment by Brandon Withrow (JIRA)

We are also experiencing this issue in the Lottie framework (airbnb/lottie-ios#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
Copy link
Contributor

swift-ci commented Nov 4, 2019

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

ReactiveKit has been hit by this issue as well (DeclarativeHub/ReactiveKit#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
Copy link
Contributor

swift-ci commented Nov 4, 2019

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
Copy link

groue commented Nov 5, 2019

Same issue here, also solved with the DEAD_CODE_STRIPPING = NO workaround : groue/GRDB.swift#640

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

@swift-ci
Copy link
Contributor

swift-ci commented Nov 5, 2019

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
Copy link
Contributor

swift-ci commented Nov 6, 2019

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
Copy link
Contributor

weissi commented Nov 10, 2019

Seen in grpc-swift + swift-nio too apple/swift-nio#1227 (comment)

@swift-ci
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

Comment by Tom Quist (JIRA)

Nimble is most likely also affected: Quick/Nimble#708

@swift-ci
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

Comment by Randy R (JIRA)

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

@swift-ci
Copy link
Contributor

swift-ci commented Dec 5, 2019

Comment by Jorge Revuelta Herrero (JIRA)

So is this solved...?❓

@weissi
Copy link
Contributor

weissi commented Dec 5, 2019

I think this is also apple/swift-nio#1294

@adam-fowler
Copy link

and soto-project/soto#208

@omochi
Copy link
Contributor

omochi commented Dec 11, 2019

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

@swift-ci
Copy link
Contributor

swift-ci commented Feb 5, 2020

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
Copy link
Contributor

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
Copy link
Contributor

Comment by Tigran Hambardzumyan (JIRA)

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

@sinoru
Copy link

sinoru commented Jul 7, 2020

Seems like still this affects to dSYM generation.

@swift-ci
Copy link
Contributor

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
Copy link

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

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@bimawa
Copy link

bimawa commented Jul 22, 2022

xcode13.4

@bimawa
Copy link

bimawa commented Jul 22, 2022

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

@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself crash Bug: A crash, i.e., an abnormal termination of software regression run-time crash Bug → crash: Swift code crashed during execution swift 5.1
Projects
None yet
Development

No branches or pull requests