JSONDecoder().decode crashes in iOS 16.1 and 16.2 Beta

Since iOS 16.1 we are getting crash reports that the the app is crashing when we call JSONDecoder.decode() using some Decodable as parameter.

Those crashes are coming from two totally different parts of the app we have not changes for over a year.

The one is our Restclient and the second the Lottie library.

BACKGROUND THREAD 13 - CRASHED
libobjc.A.dylib
objc_msgSend
CoreFoundation
__exceptionPreprocess
CoreFoundation
__NSDictionaryI_new
Foundation
newJSONObject
Foundation
newJSONValue
Foundation
newJSONValue
XX-App-AppStore

XXRestClient.RestClientImpl.(decode in _A44A6D10715BFBCEC7551A9DE0CC1D8B)<A where A: Swift.Decodable>(_: Foundation.Data?, identifier: Swift.String) -> Swift.Result<A, XXRestClientAPI.RestClientError> RestClientImpl.swift:373
XX-App-AppStore
closure #1 (Foundation.Data?, __C.NSURLResponse?, Swift.Error?) -> () in XXRestClient.RestClientImpl.(dataTask in _A44A6D10715BFBCEC7551A9DE0CC1D8B)<A where A: Swift.Decodable>(_: Foundation.URLRequest, identifier: Swift.String, handler: (Swift.Result<A, XXRestClientAPI.RestClientError>) -> ()) -> XXRestClientAPI.RestClientTask RestClientImpl.swift:229

The second stacktrace

MAIN THREAD - CRASHED
libobjc.A.dylib
objc_msgSend
CoreFoundation
____NSDictionaryI_new_block_invoke
CoreFoundation
__NSDictionaryI_new
Foundation
newJSONObject
Foundation
newJSONValue
Foundation
newJSONValue
HC-App-AppStore
function signature specialization <Arg[4] = Dead> of static Lottie.Animation.named(_: Swift.String, bundle: __C.NSBundle, subdirectory: Swift.String?, animationCache: Lottie.AnimationCacheProvider?) -> Lottie.Animation? AnimationPublic.swift:67

does anybody else experience similar issues?

Is there a Bug in iOS 16.1 ?

Post not yet marked as solved Up vote post of agiokas Down vote post of agiokas
1.3k views
  • Did you ask (AIrBnb ?) about Lottie ?

Add a Comment

Replies

Have you tried debugging your code? We can't do much here based on what you've provided.

Hello @darkpaw,

we started observing an increase in crashes on October 24th, 2022 - this was the day when iOS16.1 was released.

We see few pattern:

  • it's crashing only on iOS16.1 and later
  • it's crashing on already released versions, that worked before without crashes
  • it's crashing not only in our code (where we deserialise JSON via Decodable), but also in 3rd-party-libraries (Lottie (https://github.com/airbnb/lottie-ios/issues/1826), App-Auth (https://github.com/openid/AppAuth-iOS/issues/737))
  • in all of these crashes we can see either JSONDecoder (via Lottie) or NSJSONReader (via App-Auth), which somehow points to JSON-decoding in such cases

Do you know if anything related to that has changed in iOS16.1, which would explain such crashes suddenly?

Cheers, Andy

@darkpaw I created FB11844108 and added two crash-reports to it. Hope this help.

Thanks, Andy

I created FB11844108 and added two crash-reports to it.

Those are not Apple crash reports. If you have an Apple crash report for this problem, please post it here. See Posting a Crash Report for advice on how to do that.

And those crash reports are definitely misleading you. For example, you mentioned __exceptionPreprocess above but AFAICT that’s mis-symbolication by your third-party crash reporter. The correct symbol for that specific stack frame is ____NSDictionaryI_new_block_invoke, which makes more sense given the context.

Those crashes are coming from two totally different parts of the app we have not changes for over a year.

When generally reliable subsystems start crashing inside objc_msgSend when called from multiple contexts, that’s a strong indication that you have a memory management problem. I recommend that you deploy the standard memory debugging tools to see if you can make it more reproducible.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Thanks Quinn ;-)

    I have added some .xccrashpoint files, which I retrieved from Xcode-Organizer, to FB11844108. Hope this help pointing to the culprit.

    We already tried using the standard memory debugging tools, but have not yet been able to reproduce the crash. We'll continue trying...

    Cheers, Andy

Add a Comment