Exception Type: EXC_CRASH (SIGABRT) Caused by nanozone_error

Question

I am developing an APP, it sometimes crashes due to nanozone_error The App monitor AVAudioSessionRouteChangeNotification, and then do corresponding action such as calling [AVAudioSession currentRoute] , but sometimes, it crashed when calling this method, and inside iOS due to nanozone_error. I am confused about it. Could someone help me ?

Incident Identifier: 
CrashReporter Key:   
Hardware Model:      iPhone7,1
Process:             MyAPP 
Path:                
Identifier:          
Version:             
Code Type:           ARM-64 (Native)
Parent Process:      launchd [1]

Date/Time:           
Launch Time:         
OS Version:          iOS 8.4 (12H143)
Report Version:      105

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  26


Thread 26 name:  AVAudioSession Notify Thread
Thread 26 Crashed:
0   libsystem_kernel.dylib          0x0000000197187270 __pthread_kill + 8
1   libsystem_pthread.dylib         0x000000019722516c pthread_kill + 108
2   libsystem_c.dylib               0x00000001970feb14 abort + 108
3   libsystem_malloc.dylib          0x00000001971c23e0 nanozone_error + 316
4   libsystem_malloc.dylib          0x00000001971c254c _nano_malloc_check_clear + 360
5   libsystem_malloc.dylib          0x00000001971c1060 nano_malloc + 40
6   libsystem_malloc.dylib          0x00000001971b13e0 malloc_zone_malloc + 112
7   CoreFoundation                  0x0000000184bcae04 _CFRuntimeCreateInstance + 372
8   CoreFoundation                  0x0000000184bcbb04 CFBasicHashCreate + 108
9   CoreFoundation                  0x0000000184bcba28 CFDictionaryCreateMutable + 192
10  CoreFoundation                  0x0000000184c126a0 parseXMLElement + 2760
11  CoreFoundation                  0x0000000184c14220 getContentObject + 800
12  CoreFoundation                  0x0000000184c120c0 parseXMLElement + 1256
13  CoreFoundation                  0x0000000184c11a34 _CFPropertyListCreateFromUTF8Data + 2680
14  CoreFoundation                  0x0000000184bcb2a4 _CFPropertyListCreateWithData + 492
15  CoreFoundation                  0x0000000184bf7458 CFPropertyListCreateWithData + 100
16  AudioToolbox                    0x0000000184394c70 CADeserializer::ReadPlist() + 224
17  AudioToolbox                    0x0000000184288b6c MarshalCFPropertyList::DeserializeT(CADeserializer&, void const*&) + 28
18  AudioToolbox                    0x0000000184288ab0 TMarshaller<void const*>::Deserialize(CADeserializer&, void*&, unsigned int&) + 132
19  AudioToolbox                    0x00000001843ba6f0 PropertyMarshaller::Deserialize(unsigned int, void*&, unsigned int&, PropertyMarshaller::EClientServer) + 132
20  AudioToolbox                    0x00000001841e55a0 AudioSessionGetProperty + 620
21  libAVFAudio.dylib               0x0000000183644568 int GetProperty<__CFDictionary const*>(unsigned int, __CFDictionary const**) + 60
22  libAVFAudio.dylib               0x0000000183642460 -[AVAudioSession currentRoute] + 36
23  MyAPP                             0x000000010061bd88 -[MyAudioSession getCurrentOutputRoute] + 196

Answer 1

Unfortunately, by the time you hit nanozone_error the stack trace isn't going to tell you much because the real problem occurred somewhere else. What's going on here is that malloc_zone_malloc() tried to allocate a block of memory, which failed. It failed because _nano_malloc_check_clear(), which does a slew of checks on newly allocated blocks, found an inconsistency and threw the nanozone_error. See:

https://opensource.apple.com/source/libmalloc/libmalloc-53.1.1/src/nano_malloc.c

What probably happened is that a memory block was modified after being deallocated and returned to the heap, i.e., it wasn't properly retained. A good way to locate over-releases (or under-retains) is to set the NSZombieEnabled environment variable while debugging. In the debugging scheme, go to the "Diagnostics" tab and check "Zombie Objects". Instead of deallocating memory blocks, this turns them into "zombies", objects that stick around only to trap anything that tries to access them. Of course, this causes memory to be consumed pretty rapidly, so it shouldn't be left on permanently. For more info: https://gist.github.com/JeOam/e62c95a0b4c21974bcf6