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

tcldr · 2019-10-03T12:39:16Z


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 · 2019-10-03T17:09:20Z

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

@swift-ci create

tcldr · 2019-10-03T17:52:59Z

Yes, iOS 13.2b1!

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

eeckstein · 2019-10-07T11:09:59Z

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 · 2019-10-07T12:12:25Z

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

eeckstein · 2019-10-07T12:30:54Z

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

tcldr · 2019-10-07T12:42:41Z

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

eeckstein · 2019-10-07T12:45:17Z

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

tcldr · 2019-10-12T09:29:20Z

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

swift-ci · 2019-10-31T23:32:57Z

Comment by Randy R (JIRA)

Still happening with Xcode 11.2 final.

tcldr · 2019-10-31T23:35:21Z

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 · 2019-11-01T13:58:39Z

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 · 2019-11-01T15:20:36Z

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 · 2019-11-01T15:50:49Z

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 · 2019-11-01T16:54:31Z

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 · 2019-11-01T23:11:35Z

Comment by Randy R (JIRA)

We found a workaround.

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

swift-ci · 2019-11-02T02:09:51Z

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 · 2019-11-04T18:13:02Z

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 · 2019-11-04T21:20:28Z

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 · 2019-11-04T21:43:17Z

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 · 2019-11-05T08:12:49Z

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 · 2019-11-05T13:55:37Z

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 · 2019-11-06T20:45:51Z

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 · 2019-11-10T09:54:32Z

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

swift-ci · 2019-11-11T20:34:06Z

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 · 2019-11-11T20:40:30Z

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 · 2019-11-12T17:04:23Z

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 · 2019-11-12T21:08:54Z

Comment by Tom Quist (JIRA)

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

swift-ci · 2019-11-14T09:22:35Z

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 · 2019-11-18T18:55:50Z

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 · 2019-11-19T17:10:34Z

Comment by Randy R (JIRA)

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

swift-ci · 2019-12-05T19:19:54Z

Comment by Jorge Revuelta Herrero (JIRA)

So is this solved...?❓

weissi · 2019-12-05T23:41:07Z

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

adam-fowler · 2019-12-08T11:26:53Z

and soto-project/soto#208

omochi · 2019-12-11T06:33:46Z

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

swift-ci · 2020-02-05T16:39:10Z

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 · 2020-04-10T19:40:25Z

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 · 2020-04-16T19:41:40Z

Comment by Tigran Hambardzumyan (JIRA)

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

sinoru · 2020-07-07T02:37:07Z

Seems like still this affects to dSYM generation.

swift-ci · 2020-11-20T08:51:51Z

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 · 2021-07-04T06:59:37Z

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

bimawa · 2022-07-22T15:54:39Z

xcode13.4

bimawa · 2022-07-22T16:10:21Z

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

swift-ci transferred this issue from apple/swift-issues Apr 25, 2022

AnthonyLatsis added regression swift 5.1 and removed 5.1 regression labels Nov 20, 2022

AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022

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

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

Comments

tcldr commented Oct 3, 2019

belkadan commented Oct 3, 2019

tcldr commented Oct 3, 2019

eeckstein commented Oct 7, 2019

tcldr commented Oct 7, 2019

eeckstein commented Oct 7, 2019

tcldr commented Oct 7, 2019

eeckstein commented Oct 7, 2019

tcldr commented Oct 12, 2019

swift-ci commented Oct 31, 2019

tcldr commented Oct 31, 2019

swift-ci commented Nov 1, 2019

tcldr commented Nov 1, 2019

swift-ci commented Nov 1, 2019

swift-ci commented Nov 1, 2019

swift-ci commented Nov 1, 2019

swift-ci commented Nov 2, 2019

swift-ci commented Nov 4, 2019

swift-ci commented Nov 4, 2019

swift-ci commented Nov 4, 2019

groue commented Nov 5, 2019

swift-ci commented Nov 5, 2019

swift-ci commented Nov 6, 2019

weissi commented Nov 10, 2019

swift-ci commented Nov 11, 2019

swift-ci commented Nov 11, 2019

swift-ci commented Nov 12, 2019

swift-ci commented Nov 12, 2019

swift-ci commented Nov 14, 2019

swift-ci commented Nov 18, 2019

swift-ci commented Nov 19, 2019

swift-ci commented Dec 5, 2019

weissi commented Dec 5, 2019

adam-fowler commented Dec 8, 2019

omochi commented Dec 11, 2019

swift-ci commented Feb 5, 2020

swift-ci commented Apr 10, 2020

swift-ci commented Apr 16, 2020

sinoru commented Jul 7, 2020

swift-ci commented Nov 20, 2020

matt-curtis commented Jul 4, 2021

bimawa commented Jul 22, 2022

bimawa commented Jul 22, 2022 • edited

bimawa commented Jul 22, 2022 •

edited