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-12384] Swift._bridgeCocoaString crashes with -[NSNull _fastCStringContents:]: unrecognised selector #54821

Closed
swift-ci opened this issue Mar 19, 2020 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-12384
Radar rdar://problem/60832829
Original Reporter brunoph (JIRA User)
Type Bug
Status Resolved
Resolution Cannot Reproduce

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: 63095b9422c8a95e0fd00bc7f1f0dc44

Issue Description:

We have received these crash logs from a single user. They happened 8 times in a row, so it looks fairly consistent. My assumption is that the underlying cocoa string is (somehow) NSNull, and _bridgeCocoaString fails to handle this. I've attached one of the crash logs (the stack traces are identical on all of them).

Things of notice:

Device was running 13.3.

The last function in the stack trace that we control (makePurchaseInfo) has only two calls to something that returns a String before dispatching code using a closure that is not listed in the stack trace:

  1. A call to another class we own that reads the receipt using Bundle.main.appStoreReceiptURL and that eventually returns the data as receiptData.base64EncodedString(). However this class name is not in the stack trace, so I find it unlikely to be this.

  2. SKPaymentTransaction.payment.productIdentifier

My belief is that one of these things pointed to a NSNull instance instead of something _bridgeCocoaString understands. That's as much as I could gather from my code and from quickly glancing at StringBridge.swift in the stdlib folder of the Swift repo.

I'm ready to provide more info in case it is needed.

@beccadax
Copy link
Contributor

@swift-ci create

@lorentey
Copy link
Member

Cc @Catfish-Man

At first glance this looks like expected behavior (at least as far as bridging is concerned) – NSNull is not an NSString subclass, and trying to bridge it with Swift.String is expected to result in a runtime error.

The next step is to figure out where the bad instance comes from. If the NSNull instance is being vended by an SDK API that is declared to return NSString/String, then that's an SDK issue; can you identify the particular API?

@Catfish-Man
Copy link
Member

Another possibility would be that an NSString is being prematurely deallocated, and an NSNull ends up in its place.

@lorentey
Copy link
Member

Closing this as Cannot Reproduce for now.

brunoph (JIRA User), if this turns out to be due to a StoreKit issue, please file a Swift SDK bug through Apple's feedback assistant!

(In that case, immediately `as`-casting the value to `NSObject` will likely work around the problem.)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
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. standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

4 participants