Hi, I have multiple suspicious crashes happening shortly after application startup. They are all EXC_BAD_ACCESS/KERN_INVALID_ADDRESS coming from objc_autoreleasePoolPop. I already looked through all suspicious places which operate with unsafe pointers etc, but all that code is never executed during application startup. I'm not able to reproduce the crash myself, but it happens quite often for AppStore build. I tried using instruments, testing code compiled locally in release mode, but without any luck.
EXC_BAD_ACCESS right after app start
It looks like a URL object was prematurely destroyed. That object was in an array that was autoreleased. The crash logs don't tell us a whole lot about where that array might have come from.
You can get more information by using the Zombies template in Instruments. This will catch the first time the object is accessed after it was destroyed, and it will tell you where it was created and destroyed, along with all of the retain/release activity for that object. Please see this document for more info about how to use Zombies: https://help.apple.com/instruments/mac/current/#/dev612e6956
Thanks, but that was quite obvious. Problem is that none of those issues can be reproduced. Crashes are specific to App Store builds and are happening in random places. For example, in one of the crashes [AVCapturePhotoSettings dealloc] is called, and I never create AVCapturePhotoSettings on application start. There is a place when this object is created, but it's deep inside lifecycle. Can it be that those crashes are related to recompiling of the app by appstore/testflight?
Can it be that those crashes are related to recompiling of the app by appstore/testflight?
That App Store does not recompile your app [1]. The most common cause of problems that only show up on the App Store is the optimisation level. To investigate, find the Xcode archive that you last submitted to the App Store and export it from the organiser using Development signing. That’s exactly the same code running on user devices, and so it’s likely to replicate the crash you’re seeing.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Unless you submit bitcode, and:
-
That was only ever a requirement on watchOS and tvOS.
-
There’s no point in doing that given the changes announced in the Xcode 14 Beta Release Notes.
Bitcode is indeed enabled for our app since it was strongly encouraged before. (We are going to get rid of it ASAP, but we still have to figure out what's going wrong)
So in our case, archived app is not the same as the one executed on devices of customers.
archived app is not the same as the one executed on devices of customers.
By what metric?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
By what metric?
In case of bitcode-enabled app, the one from App Store is different from locally exported one.
is different from locally exported one.
Again, I’m curious what metric you use to assess this difference.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"