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-10828] Xcode 10.2.1 + Swift 4: NSForwarding object of class does not implement doesNotRecognizeSelector: #53218

swift-ci opened this issue Jun 4, 2019 · 3 comments


Copy link

@swift-ci swift-ci commented Jun 4, 2019

Previous ID SR-10828
Radar rdar://problem/51444402
Original Reporter beefon (JIRA User)
Type Bug

Attachment: Download


macOS 10.4.5

Xcode 10.2.1 (10E1001)


Working configuration:

Xcode 10.1 (10B61)


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

md5: e4a26fee88012b07c118102624815b26

Issue Description:

After migrating our code base to Xcode 10.2.1, I've started experiencing a crash on app start. Interestingly, if I build the same codebase using Xcode 10.1, app does not crash.

A complete stacktrace is available here:

A topmost frame's `register read` provides the following contents:

If I choose `CALLING_SOME_+initialize_METHOD` frame and inspect registers, I can find an address of an object being messaged with `+initialize`. And if I `po (BOOL)[0x0bjectAddress respondsToSelector:@selector(initialize)`, it prints YES:

By remembering ObjC, I assume it attempts to call +initialize, and then it attempts to forward that invocation.

lldb does not print any logs, but if I understand correctly, the message says that TextFieldInputView class does not implement doesNotRecognizeSelector:. The problem is that TextFieldInputView subclasses WrapperView<T>, which in turn is actually UIView.

How could I debug this and make my app not crash on start?

Copy link

@belkadan belkadan commented Jun 5, 2019

That is a heck of a backtrace, winding through several eagerly-initialized Swift types. @rjmccall, @mikeash, @slavapestov, any insights?

Copy link
Collaborator Author

@swift-ci swift-ci commented Jun 5, 2019

Comment by Vladislav Alexeev (JIRA)

I was able to fix the crash by removing one generic from our "generic chain". But looks like Swift has some troubles when there is a lot of nested types involved.

To be more precise, we had something like this:

VeryTopLevelThing<SomeComponent<WrapperComponent<SomeAnotherThing<A, B<C, D>>, AnotherStuff, BlahBlah<E, F>>>>

We had to remove WrapperComponent from this type and now app does not crash:

VeryTopLevelThing<SomeComponent<SomeAnotherThing<A, B<C, D>>, AnotherStuff, BlahBlah<E, F>>>

Copy link

@mikeash mikeash commented Jun 6, 2019

Looks like a Swift class is being treated as a root class. (All Swift classes should ultimately descend either from NSObject or SwiftObject, which implement +initialize.) Maybe it's somehow being used before its superclass field is filled out?

@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
None yet

No branches or pull requests

3 participants