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-11749] Crash only on iOS when setting subscript for non-final class in other SwiftPM module #54156

Open
swift-ci opened this issue Nov 10, 2019 · 5 comments

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Nov 10, 2019

Previous ID SR-11749
Radar None
Original Reporter mjm (JIRA User)
Type Bug

Attachment: Download

Environment

❯ xcodebuild -version
Xcode 11.2
Build version 11B52

❯ swift --version
Apple Swift version 5.1.2 (swiftlang-1100.0.278 clang-1100.0.33.9)
Target: x86_64-apple-darwin19.0.0

Issue occurs on iOS 13.2 simulators and devices. Issue does not occur on macOS 10.15. Have not tested other situations.

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Generics, Miscompile, RunTimeCrash
Assignee None
Priority Medium

md5: 41c97f70c67c490b9198ff1f08d9c0b4

duplicates:

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

Issue Description:

I've hit an issue where a custom subscript I defined on a type in one of my Swift packages is causing a crash when running on iOS, but not on macOS (either with Catalyst or not).

I've attached a minimal reproduction package, which only shows the issue when running the tests in Xcode on an iOS simulator or device. In my real use case, this issue reproduces in both test cases and when using the package from an app.

I've reduced it down to a class shaped something like this:

public class Crashy<Friend> {
    public init() {}

    private var foo: String = "bar"

    var data: [String: Any] = [:]
    public subscript(key: String) -> Any? {
        get { data[key] }
        set {
            data[key] = newValue
        }
    }
}

The crash is triggered by creating a new instance and setting the subscript with any key/value.

The following details I've found to be important (removing any of them makes the crash go away):

  • The class must be generic

  • The class must have a private variable

  • The class must be non-final

  • The class must live in a module of a Swift package (the same use case with a class in an iOS framework linked by an app does not reproduce the issue)

I've seen the crash on a stack frame like this:

#0 0x00000001060a1099 in method descriptor for UserActions.Context.subscript.modify

In the attached test case, it's much weirder, as it's referencing a different type than the one the subscript is being called on:

#0 0x0000000102a3aba8 in direct field offset for NotCrashy.data ()

@beccadax
Copy link
Contributor

@beccadax beccadax commented Nov 11, 2019

I was able to reproduce this in Xcode 10.2.1, but not with a recent master compiler. This issue may have been fixed in Swift 5.2.

@beccadax
Copy link
Contributor

@beccadax beccadax commented Nov 11, 2019

@jckarter Look familiar?

@jckarter
Copy link
Member

@jckarter jckarter commented Nov 12, 2019

Doesn't ring any bells for me, sorry. There is a subscript-adjacent miscompile bug but the one I know about only affects the master branch.

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Nov 12, 2019

Comment by Matt Moriarity (JIRA)

I just hit another case of something like this with the Entwine Swift package. In this case, there's no subscript involved, but the class is non-final, generic, and has private variables. I'm seeing iOS crash trying to access a field from a totally different class, while macOS works just fine.

@aschwaighofer
Copy link
Member

@aschwaighofer aschwaighofer commented Nov 12, 2019

This is a duplicate to SR-11564.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants