Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

iPhone crashed with tcpConnWorkQueue EXC_BAD_ACCESS

Tags:

ios

crash

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
like image 615
Sonny Saluja Avatar asked Jan 22 '14 23:01

Sonny Saluja


1 Answers

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.

like image 52
Faisal Memon Avatar answered Oct 01 '22 03:10

Faisal Memon