understanding iOS thread dump that has no application calls

Question

So I have an app that is live in the app store that I've modified to send back crash reports. This has helped me get rid of most of my bugs, but I'm having hard time identifying this one. Below is a typical crash report (I'm using PLCrashReporter).

As you can see the thread that crashes (Thread 6) has no calls to my code.
Obviously, I'm trying to understand what's causing this so I could fix it, but with no calls to my app's code, I can only guess.

I should also mention that the app is used several hundred thousands times every day, yet I only get a handful of these reports (8 in the past 24 hours), so this problem is not easily reproducible. I haven't been able to reproduce it at all.

How should I go about figuring this one out? Thank you.

The crash reports follows:

---

applicationname: MyApp
bundleidentifier: com.mycompany.MyApp
systemversion: 4.2.1
platform: iPad1,1

Process: MyApp[909]
Path: /var/mobile/Applications/A50A5AA1-4F04-405B-A295-89E13DA0760E/MyApp.app/MyApp
Identifier: com.mycompany.MyApp
Code Type: ARM (Native)
Parent Process: launchd [1]

Date/Time: 2011-03-24 11:50:49 0000
OS Version: iPhone OS 4.2.1
Report Version: 104

Exception Type: SIGBUS
Exception Codes: BUS_ADRALN at 0x10
Crashed Thread: 6

Thread 0:
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1 CoreFoundation 0x3580264f 0x357da000 165455
2 CoreFoundation 0x35801ed9 0x357da000 163545
3 CoreFoundation 0x35801c87 0x357da000 162951
4 CoreFoundation 0x35801b8f 0x357da000 162703
5 GraphicsServices 0x320c84ab 0x320c4000 17579
6 GraphicsServices 0x320c8557 0x320c4000 17751
7 UIKit 0x341dc329 0x341a5000 226089
8 UIKit 0x341d9e93 0x341a5000 216723
9 MyApp 0x00002371 0x1000 4977

Thread 1:
0 libSystem.B.dylib 0x30d30974 0x30d03000 186740
1 libSystem.B.dylib 0x30dda17c 0x30d03000 881020
2 libSystem.B.dylib 0x30dd9ba0 0x30d03000 879520
3 libSystem.B.dylib 0x30d7e251 0x30d03000 504401

Thread 2:
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1 CoreFoundation 0x3580264f 0x357da000 165455
2 CoreFoundation 0x35801ed9 0x357da000 163545
3 CoreFoundation 0x35801c87 0x357da000 162951
4 CoreFoundation 0x35801b8f 0x357da000 162703
5 WebCore 0x34bf612b 0x34b3f000 749867
6 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

Thread 3:
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1 CoreFoundation 0x3580264f 0x357da000 165455
2 CoreFoundation 0x35801ed9 0x357da000 163545
3 CoreFoundation 0x35801c87 0x357da000 162951
4 CoreFoundation 0x35801b8f 0x357da000 162703
5 Foundation 0x3118e5fd 0x31161000 185853
6 Foundation 0x3116c199 0x31161000 45465
7 Foundation 0x31165249 0x31161000 16969
8 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

Thread 4:
0 libSystem.B.dylib 0x30d2868c 0x30d03000 153228
1 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

Thread 5:
0 libSystem.B.dylib 0x30d7e9e0 0x30d03000 506336

Thread 6 Crashed:
0 libobjc.A.dylib 0x34a80464 0x34a7d000 13412
1 CoreFoundation 0x3580969f 0x357da000 194207
2 CoreFoundation 0x357e60fc 0x357da000 49404
3 CoreFoundation 0x35809623 0x357da000 194083
4 UIKit 0x341bf8d3 0x341a5000 108755
5 UIKit 0x341bf635 0x341a5000 108085
6 UIKit 0x341bf583 0x341a5000 107907
7 UIKit 0x341bf583 0x341a5000 107907
8 UIKit 0x341bf433 0x341a5000 107571
9 UIKit 0x341aa82f 0x341a5000 22575
10 UIKit 0x341c172b 0x341a5000 116523
11 UIKit 0x3420c7cd 0x341a5000 423885
12 UIKit 0x3420c6cb 0x341a5000 423627
13 UIKit 0x3420ed03 0x341a5000 433411
14 UIKit 0x3420e7f3 0x341a5000 432115
15 UIKit 0x3420cd2d 0x341a5000 425261
16 UIKit 0x3420bedd 0x341a5000 421597
17 UIKit 0x341b80cf 0x341a5000 78031
18 CoreFoundation 0x35818bbf 0x357da000 256959
19 QuartzCore 0x31075685 0x31066000 63109
20 QuartzCore 0x3107543d 0x31066000 62525
21 QuartzCore 0x3106f56d 0x31066000 38253
22 QuartzCore 0x3106f383 0x31066000 37763
23 QuartzCore 0x310c332d 0x31066000 381741
24 libSystem.B.dylib 0x30d2c26f 0x30d03000 168559
25 libSystem.B.dylib 0x30d2bf2f 0x30d03000 167727
26 libSystem.B.dylib 0x30d2be91 0x30d03000 167569
27 Foundation 0x3116c1bd 0x31161000 45501
28 Foundation 0x31165261 0x31161000 16993
29 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

Thread 6 crashed with ARM (Native) Thread State:
r0: 0x0012aa00 r1: 0x344b9f09 r2: 0x001f4790 r3: 0x34247ead
r4: 0x00000008 r5: 0x00000001 r6: 0x001df3a0 r7: 0x2ff646bc
r8: 0x344b9f09 r9: 0x00000008 r10: 0x0012aa00 r11: 0x2ff64710
r12: 0x3e82ac58 sp: 0x2ff6461c lr: 0x34247ecb pc: 0x34a80464

Answer 1

If you're using Xcode > 3.2.1 but < 4.0, you can drag that crash report file into the Organizer window, to the Device Logs section, and it'll automatically be symbolicated for you, giving you relatively nice names for the stack traces you're seeing there.

Otherwise, follow the instructions at this question to manually symbolicate it.

Answer 2

This isn't a slam dunk, but thread 6 could be releasing some toll free bridged object (like a NSString/CFStringRef). That object might have been overreleased by your code, and that over lease is either racy, or what happens to be left there is normally benign.

Failing that, can you alter your crash reporting system to collect device type data, and (non identifying) device specific data (like a UUID you stash in the prefs file if you ever discover you don't have one)? Then you could tell if for example it is from a single user or very very small pool of users (might be a hardware issue with their specific device), or a lot of users (not a hardware issue), or all the same OS release (maybe a OS bug, or at least a behavioral difference, and you're testing is narrowed down, or maybe you can drop that OS release, or a specific feature on that OS).