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

Jump to bottom

[SR-11701] Application crashes if protocol name is too long #54109

Open
swift-ci opened this issue Nov 2, 2019 · 6 comments
Open

[SR-11701] Application crashes if protocol name is too long #54109

swift-ci opened this issue Nov 2, 2019 · 6 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself IRGen LLVM IR generation

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Nov 2, 2019

Previous ID SR-11701
Radar None
Original Reporter edvaef (JIRA User)
Type Bug

Attachment: Download

Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Bug, IRGen
Assignee None
Priority Medium

md5: f2ba56d74bdb38e55a984c6909a09f22

Issue Description:

If we have a swift package (named Test for example) with code:

import Foundation

public protocol FooValueProtocol {
    associatedtype ValueType
    var value: ValueType? { get }
}

public protocol SomeLongProtocol {
    associatedtype SomeType
}

extension FooValueProtocol {
    public func some() { }
}

public final class Foo<T>: FooValueProtocol {
    public var value: T?
    public init() { }
}

And make a call from main project like this:

import Test
...
let foo = Foo<Int>()
foo.some()
...

Then we have a crash

Thread 1 Queue : com.apple.main-thread (serial)
#&#8203;0  0x00000001af0a5ec4 in __pthread_kill ()
#&#8203;1  0x00000001aefc1774 in pthread_kill$VARIANT$mp ()
#&#8203;2  0x00000001aef15844 in abort ()
#&#8203;3  0x00000001bc7a6fcc in swift_runtime_unreachable(char const*) ()
#&#8203;4  0x00000001bc7a8c24 in swift_getAssociatedConformanceWitnessSlow ()
#&#8203;5  0x00000001bc7a859c in swift_getWitnessTable ()
#&#8203;6  0x0000000100a6cb64 in lazy protocol witness table accessor for type Foo<Int> and conformance Foo<A> [inlined] ()
#&#8203;7  0x0000000100a6cb1c in AppDelegate.application(_:didFinishLaunchingWithOptions:) [inlined] at /Users/psharanda/Temp/Xcode11_2_crash/Xcode11_2_crash/AppDelegate.swift:23
#&#8203;8  0x0000000100a6cb0c in @objc AppDelegate.application(_:didFinishLaunchingWithOptions:) at /Users/psharanda/Temp/Xcode11_2_crash/<compiler-generated>:18
#&#8203;9  0x00000001b330cef4 in -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] ()
#&#8203;10 0x00000001b330ed20 in -[UIApplication _callInitializationDelegatesWithActions:forCanvas:payload:fromOriginatingProcess:] ()
#&#8203;11 0x00000001b3314554 in -[UIApplication _runWithMainScene:transitionContext:completion:] ()
#&#8203;12 0x00000001b2ae2d1c in -[_UISceneLifecycleMultiplexer completeApplicationLaunchWithFBSScene:transitionContext:] ()
#&#8203;13 0x00000001b3310664 in -[UIApplication _compellApplicationLaunchToCompleteUnconditionally] ()
#&#8203;14 0x00000001b33109bc in -[UIApplication _run] ()
#&#8203;15 0x00000001b3316768 in UIApplicationMain ()
#&#8203;16 0x0000000100a6c474 in main at /Users/psharanda/Temp/Xcode11_2_crash/Xcode11_2_crash/AppDelegate.swift:14
#&#8203;17 0x00000001af0b0360 in start ()

If change protocol name from SomeLongProtocol to SomeProtocol there is no crash. Also that protocol is not even used in main project.

Reproducible only in Xcode 11.2, only in Release mode
@swift-ci
Copy link
Collaborator Author

swift-ci commented Nov 2, 2019

Comment by Pavel Sharanda (JIRA)

Setting DEAD_CODE_STRIPPING = NO also fixes crash

@beccadax
Copy link
Contributor

beccadax commented Nov 5, 2019

What a weird bug! I was able to reproduce it in Xcode 11.2.

Steps:

  1. Unzip the attachment and open the xcodeproj.

  2. Select scheme "Xcode11_2_crash" and an iOS simulator device.

  3. Run (the project is already configured to run in release mode).

Results: Abort in swift_runtime_unreachable() during swift_getAssociatedConformanceWitnessSlow().

Conditions necessary to reproduce the bug:

  • SomeLongProtocol and FooValueProtocol must have names of 16 characters or more. (The exact name content doesn't matter.)

  • FooValueProtocol must have an associated type requirement and an extension method. (The other protocol requirements don't matter, and the extension method can be static.)

  • Foo must be generic and it must use its generic parameter to witness FooValueProtocol's associated type requirement. (The other members don't matter, although you'll at least need a typealias to set the associated type.)

  • Module name doesn't matter.

However, I couldn't reproduce it with the 11/1 master toolchain, even with the OS standard library. I haven't figured out why yet.

@theblixguy
Copy link
Collaborator

Can you try with a development toolchain? Might already be fixed on master. This is indeed a weird bug!

@beccadax
Copy link
Contributor

beccadax commented Nov 5, 2019

My best guess is that this is some kind of accidental correctness improvement from #26475 which changed how we look up protocol metadata.

@jckarter Do you see something in that change that might explain why this bug existed, or could it still be lurking in some form?

@jckarter
Copy link
Member

jckarter commented Nov 5, 2019

If disabling dead code stripping worked around the bug, then the underlying problem is likely to be either the linker bug behind SR-11564, or a bug in the compiler or linker causing metadata to be stripped that shouldn't be dead. In master, accidental dead stripping is much less likely to occur now that runtime mangled names always use embedded pointers to protocol and type descriptors, which should always be an obvious "use" of the symbol from the linker's perspective. It's possible the bug still lurks but is much less likely to be exercised because of that.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Nov 8, 2019

Comment by Matthaus Woolard (JIRA)

I can confirm i am also getting this error (Version 11.2.1 (11B53)) (or something very similar) (feedback report: FB7432118)

(see the above `ExampleCrash.zip` application, build this with release mode and it will crash on Ipad Pro) (but interestingly not on iPhone 6s or iPhone SE)

settings `DEAD_CODE_STRIPPING = NO` results in this build not crashing.

@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
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself IRGen LLVM IR generation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jckarter @beccadax @theblixguy @swift-ci