iPhone crashed with tcpConnWorkQueue EXC_BAD_ACCESS - ios

Question

I have the following stack trace:
Crashed: tcpConnWorkQueue (Not main thread)
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0xf000000c
0 libobjc.A.dylib objc_msgSend + 5
1 CoreFoundation CFRelease + 560
2 libdispatch.dylib _dispatch_call_block_and_release + 10
3 libdispatch.dylib _dispatch_queue_drain + 374
4 libdispatch.dylib _dispatch_queue_invoke + 42
5 libdispatch.dylib _dispatch_root_queue_drain + 76
6 libdispatch.dylib _dispatch_worker_thread2 + 56
7 libsystem_pthread.dylib _pthread_wqthread + 298
All the other stacks look unrelated to my code. What does this stack trace mean? And where can I look for faults in my code that may lead to something like this?
Main thread stack look like this:
Thread : com.apple.main-thread
0 QuartzCore 0x2fedef34 CA::Render::Object::unref() const + 35
1 QuartzCore 0x2fedda73 CA::Context::commit_layer(CA::Layer*, unsigned int, unsigned int, void*) + 142
2 QuartzCore 0x2fedda73 CA::Context::commit_layer(CA::Layer*, unsigned int, unsigned int, void*) + 142
3 QuartzCore 0x2fedaa23 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 314
4 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
5 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
6 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
7 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
8 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
9 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
10 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
11 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
12 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
13 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
14 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
15 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
16 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
17 QuartzCore 0x2feda9c1 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 216
18 QuartzCore 0x2fed8d41 CA::Context::commit_transaction(CA::Transaction*) + 1048
19 QuartzCore 0x2fed881f CA::Transaction::commit() + 314
20 QuartzCore 0x2ff2d929 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 516
21 IOMobileFramebuffer 0x32b5d76d IOMobileFramebufferVsyncNotifyFunc + 104
22 IOKit 0x2e7b4be5 IODispatchCalloutFromCFMessage + 248
23 CoreFoundation 0x2da92b81 __CFMachPortPerform + 136
24 CoreFoundation 0x2da9d777 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 34
25 CoreFoundation 0x2da9d713 __CFRunLoopDoSource1 + 346
26 CoreFoundation 0x2da9bedf __CFRunLoopRun + 1406
27 CoreFoundation 0x2da06471 CFRunLoopRunSpecific + 524
28 CoreFoundation 0x2da06253 CFRunLoopRunInMode + 106
29 GraphicsServices 0x327402eb GSEventRunModal + 138
30 UIKit 0x302bb845 UIApplicationMain + 1136

Answer 1

The stack trace, at level 1, shows a CFRelease has been called, but your address 0xf000000c is invalid according to the kernel, resulting in a bad access exception. This happens when a message is sent to an object already released, in the most common case.
This type of crash usually has a time lag between when the object was first released, and when it was released a second time. However, you have code which triggers when the screen is updated because you have a 0x2ff2d929 CA::Display::DisplayLink::dispatch_items.
The screen updates frequently so this should be called often.
Have you used + (CADisplayLink *)displayLinkWithTarget:(id)target selector:(SEL)sel anywhere in your program? Do you have any - (void)invalidate calls?
It could be that the user interface is switching from one use case (say playing a game with display timer based screen updates) to another (say presenting a menu choice when the game ends). When this kind of switch occurs, the code assumptions are invalidated, so you have to cancel your callbacks, else you get a final callback when things are not setup right (you draw a frame of a game when actually its time to present menus).
When you run your program with Zombies enabled -- a tick box in the Schema section, then any Released object is made a "zombie" - it lingers around waiting for calls to be made on the object. When any call comes in, it knows its a programming error and aborts. Then you can look back at the allocation history of that object to see where it was first allocated and released to identify the double-release bug.