SIGTRAP error on iOS – AutoreleasePoolPage::busted

Question

Does anyone have any clue what's causing this crash?

It happens very rarely.

The crash reports are coming via HockeyApp from the device. I've not been able to reproduce it on the simulator.

Any ideas greatly appreciated.

Exception Type:  SIGTRAP
Exception Codes: #0 at 0x197c73c10
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                      0x0000000197c73c10 _objc_trap() + 0
1   libobjc.A.dylib                      0x0000000197c73c80 _objc_fatal + 80
2   libobjc.A.dylib                      0x0000000197c8e7fc (anonymous namespace)::AutoreleasePoolPage::busted(bool) + 140
3   libobjc.A.dylib                      0x0000000197c8d54c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 88
4   CoreFoundation                       0x0000000187418f94 _CFAutoreleasePoolPop + 24
5   UIKit                                0x000000018bcd8c28 _wrapRunLoopWithAutoreleasePoolHandler + 72
6   CoreFoundation                       0x00000001874ee14c __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 28
7   CoreFoundation                       0x00000001874eb0d8 __CFRunLoopDoObservers + 356
8   CoreFoundation                       0x00000001874eb4b8 __CFRunLoopRun + 832
9   CoreFoundation                       0x00000001874191f4 CFRunLoopRunSpecific + 392
10  GraphicsServices                     0x00000001905a75a4 GSEventRunModal + 164
11  UIKit                                0x000000018bd4a784 UIApplicationMain + 1484
12  MyAppName                            0x00000001001794d4 main (main.mm:15)
13  libdyld.dylib                        0x00000001982e2a08 start + 0

Thread 1:
0   libsystem_kernel.dylib               0x00000001983e0c94 kevent64 + 8
1   libdispatch.dylib                    0x00000001982bb3b4 _dispatch_mgr_thread + 48

Thread 2:
0   libsystem_kernel.dylib               0x00000001983e0e7c mach_msg_trap + 8
1   CoreFoundation                       0x00000001874ed5cc __CFRunLoopServiceMachPort + 196
2   CoreFoundation                       0x00000001874eb520 __CFRunLoopRun + 936
3   CoreFoundation                       0x00000001874191f4 CFRunLoopRunSpecific + 392
4   CFNetwork                            0x0000000186f1d6a4 +[NSURLConnection(Loader) _resourceLoadLoop:] + 436
5   Foundation                           0x0000000188405c0c __NSThread__main__ + 1068
6   libsystem_pthread.dylib              0x0000000198497e80 _pthread_body + 160
7   libsystem_pthread.dylib              0x0000000198497ddc _pthread_start + 156
8   libsystem_pthread.dylib              0x0000000198494fb0 thread_start + 0

Thread 3:
0   libsystem_kernel.dylib               0x00000001983fb498 __select + 8
1   libsystem_pthread.dylib              0x0000000198497e80 _pthread_body + 160
2   libsystem_pthread.dylib              0x0000000198497ddc _pthread_start + 156
3   libsystem_pthread.dylib              0x0000000198494fb0 thread_start + 0

Thread 4:
0   libsystem_kernel.dylib               0x00000001983fbc78 __workq_kernreturn + 8
1   libsystem_pthread.dylib              0x0000000198494fa8 start_wqthread + 0

Thread 5:
0   libsystem_kernel.dylib               0x00000001983fbc78 __workq_kernreturn + 8
1   libsystem_pthread.dylib              0x0000000198494fa8 start_wqthread + 0

Are you creating your own auto release pools? Also, look at NSURLConnection - so this is almost for sure related to threading. My advice is to create a small demo project that only does these NSURLConnections in a fashion as close to your real code (using your real code if possible, then just run it continuously until a crash. If you can reproduce the crash you are well on your way to fix the problem. Or, you may be able to branch and adapt your real app to just continuously use its NSURLConnection code. — David H, Dec 24 '14 at 18:14
I'm not calling NSURLConnection directly in my code. Although I have got HockeyApp included. Could that be using NSURLConnection? This might also be including the exception break points mentioned by danypata – I don't entirely understand how the internals of HockeyApp work. — Paul Sturgess, Dec 25 '14 at 00:34
& yes I am creating auto release pools. In various places where I have looping code that creates a lot of intermediate variables. — Paul Sturgess, Dec 25 '14 at 00:36
One other suggestion - try adding 'activity tracing' (assuming app is for iOS8). This lets you annotate activity, and you can see that annotation in the crash log. You can google it or one link is http://www.objc.io/issue-19/activity-tracing.html. Also, I make extensive use of asserts() in my code - you can leave these enabled in a final build, and will at least get a crash at some point where you detect something wrong. Once you find this, you can with a build define essentially compile out the asserts. — David H, Dec 27 '14 at 15:56
do you have info about free available memory at the crash moment? — Vitalii Gozhenko, Dec 27 '14 at 21:52
Activity tracing looks interesting, thanks for the heads up on that. Unfortunately in this case I need to be supporting iOS7 — Paul Sturgess, Dec 28 '14 at 18:11

score 1 · Accepted Answer · answered Apr 17 '15 at 07:49

I fixed this in the end by refactoring my code.

I had blocks that I was holding on to for a navigation menu – the idea being to just call the block when a menu button was tapped.

I refactored my navigation menu buttons to no longer rely on the blocks and these AutoreleasePoolPage::busted errors disappeared.

score 0 · Answer 2 · answered Dec 27 '14 at 22:10

Strange crashes can happens when device have not enough available free memory.

This is usually different single crashes in absolutely different places.

Look attached screenshots with crash info from one of my apps

(I'm using Crashlytics for getting crash reports, it also shows information about free memory)

enter image description here

SIGTRAP error on iOS – AutoreleasePoolPage::busted

2 Answers2