App crashes in [__NSArrayM dealloc] without any other call stack information.

This crash has been troubling us for a long time. We have this crash report in every release of our App. This crash always occurs within 1 to 3 seconds after the app launched. Sometimes it happens on the main thread, sometimes on the other thread. We've never reappear it in Command+R run mode.


The call stack of the thread where the crash occurred:

Thread 0 name:
Thread 0 Crashed:
0   libobjc.A.dylib               0x00000001a8022b00 objc_object::release() + 16 (objc-object.h:532)
1   CoreFoundation                 0x00000001a8d9849c cow_cleanup + 112 (NSCollectionAux.h:70)
2   CoreFoundation                 0x00000001a8d20938 -[__NSArrayM dealloc] + 68 (NSArrayM.m:462)
3   libobjc.A.dylib               0x00000001a802338c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 676 (NSObject.mm:1605)
4   CoreFoundation                 0x00000001a8e49a44 _CFAutoreleasePoolPop + 28 (NSObject.m:1357)
5   CoreFoundation                 0x00000001a8dc508c __CFRunLoopRun + 1972 (CFRunLoop.c:3119)
6   CoreFoundation                 0x00000001a8dc45b8 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3247)
7   GraphicsServices               0x00000001ab038584 GSEventRunModal + 100 (GSEvent.c:2245)
8   UIKitCore                     0x00000001d5c6cbc8 UIApplicationMain + 212 (UIApplication.m:4341)
9   RemixLive                     0x000000010098480c main + 428044 (main.m:23)
10  libdyld.dylib                 0x00000001a8884b94 start + 4

Symbolicated crash report files:

https://github.com/developforapple/crashreportfiles/tree/master/dealloc

Replies

Symbolicated crash report files:

One of those files,

2019-01-20_05-05-50.6382_+0800-132345281579179faf78dd6d0281edffec37cea2.crash
, describes a crash that’s unrelated to this one. There your app has been killed in response to a thermal event. Check out the exception code,
0xc00010ff
, described in Technote 2151 Understanding and Analyzing iOS Application Crash Reports.

The call stack of the thread where the crash occurred:

The others crashes all have this backtrace, which clearly indicates some sort of memory management problem. Frame 4 reveals that the main thread is cleaning up its autorelease pool and something in there is triggering the crash. Frame 2 shows that this is an instance of a

NSMutableArray
(hence the
M
in
__NSArrayM
). Frame 1 is a function internal to
NSArray
involved in its copy-on-write support (hence
cow
in
cow_cleanup
).

My generical advice in situations like this is to work through the standard memory debugging tools to see if you can either force the problem to be more reproducible or catch it earlier. See my Standard Memory Debugging Tools post for links.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for your reply.

Prior to this post, I had used Zombies and Address Sanitizer to try to repeat the problem. But the crash never happened again on our device. I also checked all the code in the app that uses NSMutableArray. Through Instruments, I also check all __NSArrayM created through [__NSArrayM new:::] within 5 seconds of app launch. We got nothing. I sincerely hope to get more effective help from you. Thank you.

If Zombies and ASan don’t reveal anything, this problem is going to be harder to debug. Earlier you wrote:

We've never reappear it in Command+R run mode.

One potential cause for this is that running from Xcode usually runs the Debug build of your app, whereas customers are running the Release build. You should try reproducing this with a Release build.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

THANK YOU!

I'll keep trying.