I have a crash dump which will not symbolicate normally - when I drag it into the Xcode organizer or manually run symbolicatecrash the system symbols show up, but the application instruction addresses are all untouched.
I tried using atos to work around this problem, but the result I got was:
got symbolicator for myarchive.xcarchive/Products/Applications/MyApp.app/MyApp, base address 4000
___lldb_unnamed_function2115$$MyApp (in MyApp) + 992
___lldb_unnamed_function2096$$MyApp (in MyApp) + 66
___lldb_unnamed_function6053$$MyApp (in MyApp) + 348
___lldb_unnamed_function6064$$MyApp (in MyApp) + 162
___lldb_unnamed_function6002$$MyApp (in MyApp) + 18
___lldb_unnamed_function1029$$MyApp (in MyApp) + 416
___lldb_unnamed_function2280$$MyApp (in MyApp) + 106
___lldb_unnamed_function2272$$MyApp (in MyApp) + 198
___lldb_unnamed_function400$$MyApp (in MyApp) + 96
___lldb_unnamed_function1$$MyApp (in MyApp) + 36
The address currently getting mapped to ___lldb_unnamed_function1$$MyApp (in MyApp) + 36 should correspond to my root invocation in main.m. Obviously, I don't know what the others should be, but I'm guessing that if one is wrong they're all wrong. What could cause this? Does ___lldb_unnamed_function normally appear anywhere other than functions embedded in blocks?
Unfortunately, this will make for a long question, but since it could be an error in calculating the load offset of the app binary I'll list the steps that I followed to yield the above output.
I used dwarfdump -u myarchive.xcarchive/Products/Applications/MyApp.app/MyApp to verify that I am using the correct binary:
UUID: BA41E9A3-4BB5-3F8A-8D57-0D16447FFEC6 (armv7) myarchive.xcarchive/Products/Applications/MyApp.app/MyApp
UUID: A6E0970C-05FE-3A79-887D-84F3892637FD (armv7s) myarchive.xcarchive/Products/Applications/MyApp.app/MyApp
The UUID in the crash dump matches the first one:
Binary Images:
0x97000 - 0x3cefff +MyApp armv7 <ba41e9a34bb53f8a8d570d16447ffec6> /var/mobile/Applications/AF97EC52-7A2F-4772-AA05-74E739BA6882/MyApp.app/MyApp
This line also lists the load offset as 0x97000 and the architecture as armv7. The addresses I'm interested in are:
1 MyApp 0x001357dc 0x97000 + 649180
2 MyApp 0x00134446 0x97000 + 644166
3 MyApp 0x00240cec 0x97000 + 1744108
4 MyApp 0x002416ea 0x97000 + 1746666
5 MyApp 0x0023e2de 0x97000 + 1733342
6 MyApp 0x000de724 0x97000 + 292644
7 MyApp 0x00144f1a 0x97000 + 712474
8 MyApp 0x00144336 0x97000 + 709430
27 MyApp 0x000b1024 0x97000 + 106532
28 MyApp 0x0009d464 0x97000 + 25700
So I ran xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive/Products/Applications/MyApp.app/MyApp 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de724 0x00144f1a 0x00144336 0x000b1024 0x0009d464, which gave me the output above.
Note: since this didn't look correct, I thought perhaps I needed to manually subtract the slide value. I obtained it from the app bundle with xcrun otool -arch armv7 -l myarchive.xcarchive/Products/Applications/MyApp.app/MyApp:
Load command 0
cmd LC_SEGMENT
cmdsize 56
segname __PAGEZERO
vmaddr 0x00000000
vmsize 0x00004000
fileoff 0
filesize 0
maxprot 0x00000000
initprot 0x00000000
nsects 0
flags 0x0
Load command 1
cmd LC_SEGMENT
cmdsize 736
segname __TEXT
vmaddr 0x00004000
vmsize 0x00338000
fileoff 0
filesize 3375104
maxprot 0x00000005
initprot 0x00000005
nsects 10
<snip>
However, rerunning the command with -l 0x93000 gave me a very similar result:
got symbolicator for /Users/arkaaito/Library/Developer/Xcode/Archives/2013-11-07/Zoomingo 11-7-13, 2.14 PM.xcarchive/Products/Applications/Zoomingo.app/Zoomingo, base address 4000
___lldb_unnamed_function2166$$Zoomingo (in Zoomingo) + 684
___lldb_unnamed_function2160$$Zoomingo (in Zoomingo) + 182
___lldb_unnamed_function6165$$Zoomingo (in Zoomingo) + 164
___lldb_unnamed_function6176$$Zoomingo (in Zoomingo) + 46
___lldb_unnamed_function6114$$Zoomingo (in Zoomingo) + 70
___lldb_unnamed_function1129$$Zoomingo (in Zoomingo) + 28
___lldb_unnamed_function2305$$Zoomingo (in Zoomingo) + 2446
___lldb_unnamed_function2302$$Zoomingo (in Zoomingo) + 3714
___lldb_unnamed_function476$$Zoomingo (in Zoomingo) + 512
___lldb_unnamed_function85$$Zoomingo (in Zoomingo) + 532
You have to call atos with the dSYM package, not the app bundle since that normally has the symbols stripped!
So the call is:
xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive/dSYMs/MyApp.app.dSYM 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de724 0x00144f1a 0x00144336 0x000b1024 0x0009d464
Related
update:
VNC into the build machine (without making any changes) somehow fixes this....strange
Context
We use Mac EC2 instances CI cluster to run UI tests. The cluster is set up to recycle every night. Meaning new cluster is provisioned in the morning. We notice that the tests get increasing more and more flaky throughout the day.
Build 312 is the first build in the morning.
Red is failed tests, Orange is silenced tests, Yellow is flaky tests, Grey is unknown status
The commit are just white space auto commit that trigger off builds. The tests content are the same.
Note: Bluepill configure to run one Simulator per machine (no concurrency)
Log
The flaky test or failure are usually due to "waiting for some resource to idle" and reach timeout, or some network request to finish. The tests that failed or flaky also has a commonality which is they are usually related to video
Here are a couple sample logs
Waiting for app to idle
Timed out waiting for app to idle.
The following idling resources are busy.
1. GREYAppStateTracker:
Waiting for network requests to finish. By default, EarlGrey tracks all network requests. To change this behavior, refer to GREYConfiguration.
<__NSCFLocalDataTask:0x7fcfcfd87450, URL:"https://v.myorgimg.com/videos/mc/hls/e7/01/ca/e701caebac12684056eb699f316fc411_360w.m3u8"> => Waiting for network requests to finish. By default, EarlGrey tracks all network requests. To change this behavior, refer to GREYConfiguration.
(
0 MyorgDevelopmentEG2 0x000000010ebf3205 -[GREYAppStateTrackerObject setState:] + 69
1 MyorgDevelopmentEG2 0x000000010ebf22b3 __133-[GREYAppStateTracker grey_changeState:usingOperation:forObject:orInternalObjectDeallocationTracker:orExternalAppStateTrackerObject:]_block_invoke + 931
2 MyorgDevelopmentEG2 0x000000010ebf18f0 -[GREYAppStateTracker grey_performBlockInCriticalSection:] + 224
3 MyorgDevelopmentEG2 0x000000010ebf1e34 -[GREYAppStateTracker grey_changeState:usingOperation:forObject:orInternalObjectDeallocationTracker:orExternalAppStateTrackerObject:] + 1076
4 MyorgDevelopmentEG2 0x000000010ebf0ac6 -[GREYAppStateTracker trackState:forObject:] + 102
5 MyorgDevelopmentEG2 0x000000010ebca867 -[__NSCFLocalDataTask_GREYApp grey_track] + 135
6 MyorgDevelopmentEG2 0x000000010ebcac55 -[__NSCFLocalDataTask_GREYApp greyswizzled_resume] + 181
7 MediaToolbox 0x00007fff2b617285 figHttpRequestSetupNSURLSessionTask + 1380
8 MediaToolbox 0x00007fff2b616bb6 _FigHTTPRequestCreateWithNSURLSession + 2923
9 MediaToolbox 0x00007fff2b64aaaf figHTTPRequestSessionNSCreateHTTPRequest + 199
10 MediaToolbox 0x00007fff2b71f5b1 segPumpCreateHTTPRequest + 944
11 MediaToolbox 0x00007fff2b721de6 segPumpSendIndexFileRequest + 1703
12 MediaToolbox 0x00007fff2b7431d5 segPumpRequestIndexForStream + 753
13 MediaToolbox 0x00007fff2b7421ee segPumpSetAlternateForStream + 3145
14 MediaToolbox 0x00007fff2b73e9e5 segPumpSetCurrentAlternate + 9898
15 MediaToolbox 0x00007fff2b791d6a ProduceStreamingAssetProperty + 661
16 MediaToolbox 0x00007fff2b78e07c URLAssetPropertyWorkFunction + 872
17 libdispatch.dylib 0x00007fff201078df _dispatch_client_callout + 8
18 libdispatch.dylib 0x00007fff2010de15 _dispatch_lane_serial_drain + 715
19 libdispatch.dylib 0x00007fff2010e9c3 _dispatch_lane_invoke + 455
20 libdispatch.dylib 0x00007fff20117a8e _dispatch_root_queue_drain + 350
21 libdispatch.dylib 0x00007fff2011786c _dispatch_worker_thread + 222
22 libsystem_pthread.dylib 0x00007fff60342950 _pthread_start + 224
23 libsystem_pthread.dylib 0x00007fff6033e47b thread_start + 15
)
and waiting for network request to finish
9. GREYAppStateTracker:
Waiting for network requests to finish. By default, EarlGrey tracks all network requests. To change this behavior, refer to GREYConfiguration.
Waiting for UIView's draw/layout pass to complete. A draw/layout pass normally completes in the next runloop drain.
<ASCollectionView: 0x7feca21ad000> => Waiting for UIView's draw/layout pass to complete. A draw/layout pass normally completes in the next runloop drain.
(
0 MyorgDevelopmentEG2 0x000000010bb2e335 -[GREYAppStateTrackerObject setState:] + 69
1 MyorgDevelopmentEG2 0x000000010bb2d3e3 __133-[GREYAppStateTracker grey_changeState:usingOperation:forObject:orInternalObjectDeallocationTracker:orExternalAppStateTrackerObject:]_block_invoke + 931
2 MyorgDevelopmentEG2 0x000000010bb2ca20 -[GREYAppStateTracker grey_performBlockInCriticalSection:] + 224
3 MyorgDevelopmentEG2 0x000000010bb2cf64 -[GREYAppStateTracker grey_changeState:usingOperation:forObject:orInternalObjectDeallocationTracker:orExternalAppStateTrackerObject:] + 1076
4 MyorgDevelopmentEG2 0x000000010bb2bbf6 -[GREYAppStateTracker trackState:forObject:] + 102
5 MyorgDevelopmentEG2 0x000000010bb02b0d -[UIView(GREYApp) greyswizzled_setNeedsLayout] + 93
6 UIKitCore 0x00007fff24ba5675 -[UIScrollView setNeedsLayout] + 79
7 UIKitCore 0x00007fff23dc0390 -[UICollectionView _updateAnimationDidStop:finished:context:] + 2236
8 UIKitCore 0x00007fff23dbf9e4 __102-[UICollectionView _updateWithItems:tentativelyForReordering:propertyAnimator:collectionViewAnimator:]_block_invoke.2110 + 77
9 MyorgDevelopmentEG2 0x000000010bb2fdef __60-[GREYDispatchQueueTracker grey_dispatchAsyncCallWithBlock:]_block_invoke + 47
10 libdispatch.dylib 0x00007fff2010670d _dispatch_call_block_and_release + 12
11 libdispatch.dylib 0x00007fff201078df _dispatch_client_callout + 8
12 libdispatch.dylib 0x00007fff20114a27 _dispatch_main_queue_callback_4CF + 1045
13 CoreFoundation 0x00007fff203908f8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
14 CoreFoundation 0x00007fff2038b169 __CFRunLoopRun + 2781
15 CoreFoundation 0x00007fff2038a1a7 CFRunLoopRunSpecific + 567
16 GraphicsServices 0x00007fff2b874d85 GSEventRunModal + 139
17 UIKitCore 0x00007fff246c14df -[UIApplication _run] + 912
18 UIKitCore 0x00007fff246c639c UIApplicationMain + 101
19 MyorgDevelopmentEG2 0x0000000108f175de main + 190
20 libdyld.dylib 0x00007fff2025abbd start + 1
21 ??? 0x0000000000000005 0x0 + 5
)
<_ASDisplayLayer: 0x600007996580> => Waiting for UIView's draw/layout pass to complete. A draw/layout pass normally completes in the next runloop drain.
Hypothesis
This leads me to think there are some orphaned subprocess or daemon that still holds onto to resources. Or there are artifacts not being clean up properly.
Things I have tried
shutdown, erase, delete all simulator between builds (No Help)
xcrun simctl shutdown all
xcrun simctl erase all
xcrun simctl delete all
osascript -e 'tell application "iOS Simulator" to quit'
osascript -e 'tell application "Simulator" to quit'
Kill CoreSimulator related services between builds (No Help)
launchctl remove com.apple.CoreSimulator.CoreSimulatorService || true
launchctl remove com.apple.CoreSimulator.SimLaunchHost-x86 || true
launchctl remove com.apple.CoreSimulator.SimulatorTrampoline || true
launchctl remove com.apple.CoreSimulator.SimLaunchHost-arm64 || true
delete simulator devices, logs, and cache between builds. This actually helped a bit. The flakiness went away initially but came back quickly after a few builds while the machines still performing the cleaning between builds....unsure why.
echo "Delete all simulator devices, cache, and temp"
rm -rf ~/Library/Developer/CoreSimulator
echo "Delete Simulator Logs"
rm -rf ~/Library/Logs/CoreSimulator
Increase Animation Timeout, Interaction Timeout, on EarlGrey
Blacklist the URL the request hung on. This did improve the stability of the test suite by ignoring the symptom and not fixing the actual probelm so I am hoping I can avoid this.
Anyone else running into the same issue? Appreciate if someone can shed any light on this or give suggestions to try.
Note: We uses Bluepill and EarlGrey2 to run UI tests (iOS 14.5, Xcode 12.5) on Buildkite CI pipeline.
Have you tried running:
sudo systemsetup -setcomputersleep never
I am developing an Application for iOS and I changed nothing in the Application. But at a restart of my Mac, Xcode crashes every time.
Don't know if this is important, but my spotlight can't find any applications and also when I open the finder and using the shortcut cmd + shift + H I see a white window.
Xcode isn't starting anymore and throws this error:
Process: Xcode [1346]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 7.2 (9548)
Build Info: IDEFrameworks-9548000000000000~7
App Item ID: 497799835
App External ID: 814662604
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Xcode [1346]
Date/Time: 2015-12-24 11:01:44.753 +0100
OS Version: Mac OS X 10.11.2 (15C50)
Report Version: 11
Time Awake Since Boot: 4000 seconds
System Integrity Protection: enabled
Crashed Thread: 4 Dispatch queue: DVTFilePathEventWatcher - event queue
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0:
-->
__TEXT 0000000108a5a000-0000000108a5e000 [ 16K] r-x/rwx SM=COW /Applications/Xcode.app/Contents/MacOS/Xcode
Application Specific Information:
ProductBuildVersion: 7C68
Thread 0:: Dispatch queue: DVTFilePath cache derivation lock for key DVTFilePathKey_SortedDirectoryContents
0 libobjc.A.dylib 0x00007fff8df27aa0 search_method_list(method_list_t const*, objc_selector*) + 2
1 libobjc.A.dylib 0x00007fff8df28d76 lookUpImpOrForward + 413
2 libobjc.A.dylib 0x00007fff8df22591 objc_msgSend + 209
3 com.apple.dt.DVTFoundation 0x0000000108a741f8 -[DVTFileSystemVNode addCachedEntriesFromDictionary:] + 215
4 com.apple.dt.DVTFoundation 0x0000000108bd2e2d __33-[DVTFilePath cachedValueForKey:]_block_invoke549 + 245
5 libdispatch.dylib 0x00007fff9fcbd33f _dispatch_client_callout + 8
6 libdispatch.dylib 0x00007fff9fcbe926 _dispatch_barrier_sync_f_invoke + 74
7 com.apple.dt.DVTFoundation 0x0000000108cd1005 DVTDispatchBarrierSync + 62
8 com.apple.dt.DVTFoundation 0x0000000108a69627 -[DVTDispatchLock performLockedBlock:] + 116
9 com.apple.dt.DVTFoundation 0x0000000108a715b0 -[DVTFilePath cachedValueForKey:] + 1802
10 com.apple.dt.DVTFoundation 0x0000000108a70afc -[DVTToolchainRegistry scanSearchPathAndRegisterToolchains:] + 563
11 com.apple.dt.IDEFoundation 0x00000001097d1a66 IDEInitialize + 655
12 com.apple.dt.IDEKit 0x0000000109ecdf7c -[IDEApplicationController applicationWillFinishLaunching:] + 708
13 com.apple.CoreFoundation 0x00007fffa18fa70c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
14 com.apple.CoreFoundation 0x00007fffa18fa67f ___CFXRegistrationPost_block_invoke + 63
15 com.apple.CoreFoundation 0x00007fffa18f9d47 _CFXRegistrationPost + 407
16 com.apple.CoreFoundation 0x00007fffa18f9ab2 ___CFXNotificationPost_block_invoke + 50
17 com.apple.CoreFoundation 0x00007fffa18f3d42 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1922
18 com.apple.CoreFoundation 0x00007fffa17e2145 _CFXNotificationPost + 693
19 com.apple.Foundation 0x00007fff9ef36921 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
20 com.apple.dt.DVTFoundation 0x0000000108c6cf55 -[NSNotificationCenter(DVTNSNotificationCenterAdditions) _dvt_postNotificationName:object:userInfo:] + 698
21 com.apple.AppKit 0x00007fff9db412c2 -[NSApplication finishLaunching] + 354
22 com.apple.dt.DVTKit 0x0000000109275f62 -[DVTApplication finishLaunching] + 149
23 com.apple.AppKit 0x00007fff9db40e05 -[NSApplication run] + 231
24 com.apple.AppKit 0x00007fff9dac3520 NSApplicationMain + 1176
25 libdyld.dylib 0x00007fff9a8605ad start + 1
Could this be an issue due to Permissions conflicts?
ANSWER:
After I changed the rights from my OSX-Drive to everyone can write&read. Everything worked. But I knew that this is a temporary solution, so I decided to reinstall my MAC and everything was fine.
Delete ~/Library/Developer/Xcode/DerivedData by running this command in terminal:
rm -r ~/Library/Developer/XCode/DerivedData
If that doesnt work, At this point and with given info, all I could recommend to delete and reinstall Xcode.
If the delete of ~/Library/Developer/Xcode/DerivedData is not working for you, try this steps to remove xcuserdata:
open a Finder window and navigate to your project
right-click on the .xcodeproj OR .xcworkspace file
select Show Package Contents
a new window appears
delete a folder called xcuserdata
I had one where i selected a file that was quite large which crashed xcode when it tried to parse it. Then when i restarted it somehow it got set to load that file on start. Only way i saw was to temporarily rename the file that it was trying to load at start so it would load empty.
I'll recommend deleting xcuserdata: folder from both of your .xcodeproj & .xcworkspace file (open with Show Package Contents) and try again.
I hope this will work.
Ensure there are no issues with your SPM packages/dependencies.
This is simply another suggestion. I just spent some time debugging this on a fairly popular open source project.
My Xcode first crashed when I updated a SPM package, so I was fairly certain it was an issue with one of the future commits in that package or a SPM bug. I subscribe to Occam's Razor, so I started going through the changes in the commits.
After some time, I found a duplicate Swift Playground page delcaration in contents.xcplayground. I removed that single line, pushed the PR, and everything worked fine after that.
To be able to reopen the project:
Open project.pbxproj in your code editor of choice (e.g. vi, nano, emacs, atom, code).
Remove the offending package or packages from the /* Begin XCRemoteSwiftPackageReference section */ and /* Begin XCSwiftPackageProductDependency section */ sections.
Save the file and Xcode should now open.
Again, if your Xcode is immediately crashing when opening a project (and you last updated/auto-updated a SPM package) go through your packages.
My app is occasionally crashing for some users and I have been unable to replicate the problem.
I have managed to get a few crash reports from one of the users which I have imported to Xcode, but I am unable to symbolicate the reports fully with some of the myApp lines not showing the actual class/code being called. Two sample stack traces extracts:
Last Exception Backtrace:
0 CoreFoundation 0x39e5c3e2 __exceptionPreprocess + 158
1 libobjc.A.dylib 0x38eb595e objc_exception_throw + 26
2 CoreFoundation 0x39da66d0 -[__NSPlaceholderArray initWithObjects:count:] + 160
3 CoreFoundation 0x39da6e04 +[NSArray arrayWithObject:] + 40
4 myApp 0x0012117c 0x63000 + 778620
5 myApp 0x0012c700 0x63000 + 825088
6 myApp 0x00148784 0x63000 + 939908
7 myApp 0x0013caf0 0x63000 + 891632
8 myApp 0x0013b9da 0x63000 + 887258
9 myApp 0x0006bda2 -[myAppAppDelegate init] (myAppAppDelegate.m:45)
10 UIKit 0x3380d8aa -[UIClassSwapper initWithCoder:] + 186
Last Exception Backtrace:
0 CoreFoundation 0x39e5c3e2 __exceptionPreprocess + 158
1 libobjc.A.dylib 0x38eb595e objc_exception_throw + 26
2 CoreFoundation 0x39da66d0 -[__NSPlaceholderArray initWithObjects:count:] + 160
3 CoreFoundation 0x39da6e04 +[NSArray arrayWithObject:] + 40
4 myApp 0x000c217c 0x4000 + 778620
5 myApp 0x000cd700 0x4000 + 825088
6 myApp 0x000e9784 0x4000 + 939908
7 myApp 0x000ddaf0 0x4000 + 891632
8 myApp 0x000dc9da 0x4000 + 887258
9 myApp 0x0000cda2 -[myAppAppDelegate init] (myAppAppDelegate.m:45)
10 UIKit 0x3380d8aa -[UIClassSwapper initWithCoder:] + 186
This is an app submitted to the store from an archived build which still exists in Xcode. I have also tried the atos command, and running several of the symbolicate scripts available with no success. (I am 100% sure I have the correct .app and .dSYM files).
Anyone have any idea how I may be able to find out more info about these stack traces and determine where this crash is happening?
(Note: I am aware that line 9 references the app delegate's init command, which is very useful. My question is specifically regarding the subsequent calls that are not symbolicated)
Thanks!
I'm using the atos command to symbolicate crash logs.
I have this crash stack :
0 MyApp 0x001c4389 MyApp + 1848201
1 MyApp 0x001c49f1 MyApp + 1849841
2 libsystem_c.dylib 0x33f1f7ed _sigtramp + 48
3 libsystem_c.dylib 0x33f1520f pthread_kill + 54
4 libsystem_c.dylib 0x33f0e29f abort + 94
5 MyApp 0x00021843 MyApp + 133187
6 MyApp 0x00005569 MyApp + 17769
7 MyApp 0x00022b9b MyApp + 138139
8 MyApp 0x0000637b MyApp + 21371
Let's symbolicate the line 6 :
atos -arch armv7 -o MyApp.app/MyApp 0x00005569
=> -[MyAppCoreDataManager persistentStoreCoordinatorForUpdate] (in MyApp) (MyAppCoreDataManager.m:176)
Perfect, but line 5 :
atos -arch armv7 -o Popcarte.app/Popcarte 0x00021843
=> 0x00021843 (in MyApp) + 47
I think it references a #synthesize, but i'm not sure, and I would like to know which one.
Is there a way to know more about this result ?
I have crash logs and put it in XCode.
Xcode symbolicate all foundation symbols but not my app:
2 UIKit 0x317fd1a8 -[UITableView selectRowAtIndexPath:animated:scrollPosition:] + 24
3 myApp 0x0001f084 0x1000 + 123012
4 myApp 0x0001d6da 0x1000 + 116442
5 myApp 0x0000643c 0x1000 + 21564
6 myApp 0x00031dfc 0x1000 + 200188
7 CoreFoundation 0x355df42e -[NSObject performSelector:withObject:withObject:] + 46
8 UIKit 0x317659e4 -[UIApplication sendAction:to:from:forEvent:] + 56
9 UIKit 0x3182b3c8 -[UIBarButtonItem(UIInternal) _sendAction:withEvent:]
How can I symbolicate my app symbols?
You can use a symbolicatecrash utile (perl script provided with Xcode). And you need .dsym file, it was generated during building you app. For each build you need to have .dsym file (it usually stored somewhere near your output binary).
Also, you may use option "Strip debug symbols during copy" (set it to NO) in your project options to save symbols in your bundle.
Good luck!
try setting "Deployment Postprocessing" to NO and make sure you're building everything in debug mode