iPhone 앱 충돌 보고서 상징

iPhone 앱 충돌 보고서 상징

---

iPhone 앱의 충돌 보고서를 시도하고 상징화하려고합니다.

iTunes Connect에서 충돌 보고서를 검색했습니다. App Store에 제출 한 응용 프로그램 바이너리가 있으며 빌드의 일부로 생성 된 dSYM 파일이 있습니다.

스포트 라이트로 색인이 생성 된 단일 디렉토리 안에 이러한 파일을 모두 가지고 있습니다.

지금 무엇?

나는 호출을 시도했다 :

symbolicatecrash crashreport.crash myApp.app.dSYM

충돌 보고서에있는 것과 동일한 텍스트를 기호화하지 않고 시작합니다.

내가 뭔가 잘못하고 있습니까?

---

애플의 충돌 보고서를 분석하는 단계 :

1. appstore로 푸시 된 릴리스 .app 파일, 릴리스시 작성된 .dSYM 파일을 복사하고 충돌 보고서가 APPLE에서 FOLDER 로 수신됩니다 .

2. 터미널 응용 프로그램을 열고 위에서 만든 폴더로 이동하십시오 ( cd명령 사용 )

3. 를 실행하십시오 atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. 메모리 위치는 보고서에 따라 앱이 중단 된 위치 여야합니다.

전의: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

이것은 정확한 줄, 메소드 이름을 표시하여 충돌을 일으켰습니다.

전의: [classname functionName:]; -510

상징적 인 IPA

IPA를 상징화하는 데 사용한다면 확장자 .ipa의 이름을 .zip으로 바꾸고 추출하면 앱이 포함 된 페이로드 폴더를 얻을 수 있습니다. 이 경우 .dSYM 파일이 필요하지 않습니다.

노트

앱 바이너리에 심볼이 제거되지 않은 경우에만 작동합니다. 기본적으로 릴리스 빌드는 심볼을 제거했습니다. 프로젝트 빌드 설정 "복사 중 스트립 디버그 기호"에서 NO로 변경할 수 있습니다.

자세한 내용은이 게시물을 참조하십시오

---

충돌 로그를 상징화하기 위해 여기에 모든 대답을 읽은 후에 (그리고 마침내 성공합니다) 나는 symbolicatecrash 호출이 상징적 인 출력을 생성하지 않는 이유를 결정하기 위해 실제로 중요한 몇 가지 요점이 있다고 생각합니다.

충돌 로그를 상징화 할 때 함께 맞아야하는 3 가지 자산이 있습니다.

1. example.crashXCode의 Organizer에서 내보내거나 iTunes Connect에서받은 충돌 로그 파일 자체 (예 :).
2. 충돌 로그에 속하는 앱 바이너리가 포함 된 .app패키지 (예 example.app:) 당신이있는 경우 .ipa(즉, 패키지 example.ipa) 다음은 추출 할 수 있습니다 .app의 압축을 해제하여 패키지를 .ipa패키지 (즉 unzip example.ipa). 그 후 .app패키지는 추출 된 Payload/폴더에 있습니다.
3. .dSYM디버그 기호를 포함하는 패키지 (예 example.app.dSYM)

기호화를 시작하기 전에 모든 해당 아티팩트가 일치하는지 확인해야합니다. 이는 충돌 로그가 사용자가 보유한 2 진에 속해 있고 디버그 기호가 해당 2 진 빌드 중에 생성 된 것임을 의미합니다.

각 바이너리는 충돌 로그 파일에서 볼 수있는 UUID에 의해 참조됩니다.

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

이 추출에서 충돌 로그는 UUID가있는 example.app/example이라는 앱 이진 이미지에 속합니다 aa5e633efda8346cab92b01320043dc3.

dwarfdump로 가지고있는 바이너리 패키지의 UUID를 확인할 수 있습니다.

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

그런 다음 디버그 기호가 해당 바이너리에 속하는지 확인해야합니다.

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

이 예에서는 모든 자산이 함께 맞으며 스택 추적을 상징 할 수 있어야합니다.

symbolicatecrash스크립트 진행 :

Xcode 8.3에서는 다음을 통해 스크립트를 호출 할 수 있어야합니다.

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

존재하지 않으면 find . -name symbolicatecrashXcode.app 디렉토리에서 a 를 실행 하여 찾을 수 있습니다.

보시다시피 더 이상 매개 변수가 제공되지 않습니다. 따라서 스크립트는 스포트라이트 검색을 실행하여 애플리케이션 바이너리 및 디버그 기호를 찾아야합니다. 이라는 특정 인덱스로 디버그 기호를 검색합니다 com_apple_xcode_dsym_uuids. 이 검색을 직접 수행 할 수 있습니다.

mdfind 'com_apple_xcode_dsym_uuids = *'

각하

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

첫 번째 스포트라이트 호출은 모든 색인화 된 dSYM 패키지를 제공하고 두 번째 스포트라이트 호출은 .dSYM특정 UUID를 가진 패키지를 제공합니다 . 스포트라이트가 .dSYM패키지를 찾지 못하면 symbolicatecrash둘 중 하나도 아닙니다. 예를 들어 ~/Desktop스포트라이트 의 하위 폴더에서이 모든 작업을 수행하면 모든 것을 찾을 수 있어야합니다.

경우 symbolicatecrash귀하의 발견 .dSYM패키지를 다음에 같은 라인이 있어야한다 symbolicate.log:

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

.app패키지 를 찾기 위해 다음과 같은 스포트라이트 검색이 호출됩니다 symbolicatecrash.

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

경우 symbolicatecrash귀하의 발견 .app패키지에 다음 추출물이 있어야한다 symbolicate.log:

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

이러한 모든 리소스가 발견 symbolicatecrash되면 기호화 된 버전의 충돌 로그를 인쇄해야합니다.

그렇지 않은 경우 dSYM 및 .app 파일을 직접 전달할 수 있습니다.

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

참고 : 기호화 된 역 추적은 아닌 터미널로 출력됩니다 symbolicate.log.

---

최신 버전의 Xcode (3.2.2)를 사용하면 충돌 보고서를 Xcode Organizer의 장치 로그 섹션으로 끌어서 놓을 수 있으며 자동으로 기호로 표시됩니다. Build & Archive (Xcode 3.2.2의 일부)를 사용하여 해당 버전의 앱을 빌드 한 경우 이것이 가장 효과적이라고 생각합니다

---

다음 단계를 사용하여 성공적으로 수행했습니다.

1 단계 : 바탕 화면에 폴더를 만들고 이름을 "CrashReport"로 지정하고 세 개의 파일 ( "MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07-18.crash")을 넣습니다.

2 단계 : Finder를 열고 Xcode 응용 프로그램을 찾을 수있는 응용 프로그램으로 이동하십시오. 이곳을 마우스 오른쪽 버튼으로 클릭하고 "패키지 내용보기"를 클릭하십시오.이 간단한 경로를 따라 가십시오. "내용-> 개발자-> 플랫폼-> iPhoneOS.platform-> 개발자 -> 라이브러리 -> PrivateFrameworks-> DTDeviceKit.framework- > 버전-> A-> 자원"

또는

"내용-> 개발자-> 플랫폼-> iPhoneOS.platform-> 개발자 -> 라이브러리 -> PrivateFrameworks-> DTDeviceKitBase.framework- > 버전-> A-> 자원"

또는

Xcode 6 이상의 경우 경로는 Applications / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Resources입니다.

"symbolicatecrash"파일을 찾으면이를 복사하여 "CrashReport"폴더에 붙여 넣으십시오.

3 단계 : 터미널을 시작하고이 3 개의 명령을 실행하십시오.

1. cd / Users / mac38 / Desktop / CrashReport를 입력하고 Enter 버튼을 누릅니다

2. DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer"를 내보내고 Enter를 누르십시오.

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM을 입력하고 Enter Now를 누르십시오. (참고 : 6.4 이상의 버전에는 -A 옵션이 없습니다. 그냥 두십시오).

---

XCode를 사용하여 충돌 보고서를 자동으로 상징하는 단계 :

XCODE 9 용으로 업데이트

1. 연결 어떤 (예 물리적 하나, 그래 난이 바보 알고) Mac에 iOS 장비를

2. "창"메뉴에서 "장치"를 선택하십시오

3. 왼쪽에서 기기를 클릭하고 오른쪽에서 기기 로고보기

4. 기다림. 표시되는 데 1 분 정도 걸릴 수 있습니다. 어쩌면 일을 Command-A한 다음 Delete이 속도를 높일 것입니다.

5. 문서화되지 않은 중요한 단계 : iTunesConnect에서 가져온 충돌 보고서.txt를.crash확장에서확장으로이름을 바꿉니다.

6. 충돌 보고서를 왼쪽의 해당 영역으로 드래그하십시오.

그런 다음 Xcode는 충돌 보고서를 상징하고 결과를 표시합니다.

출처 : https://developer.apple.com/library/ios/technotes/tn2151/_index.html

---

내 앱에서 Airbrake를 사용하는데, 이는 원격 오류 로깅을 상당히 잘 수행합니다.

백 트레이스에 필요한 경우 atos로 상징하는 방법은 다음과 같습니다.

1. Xcode (4.2)에서 Organizer로 이동하여 .ipa 파일이 생성 된 아카이브를 마우스 오른쪽 버튼으로 클릭하십시오.

2. 터미널에서 예를 들어 xcarchive로 cdMyCoolApp 10-27-11 1.30 PM.xcarchive

3. 다음을 입력하십시오 atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp'(작은 따옴표를 잊지 마십시오)

4. 나는 그 전화에 나의 상징을 포함시키지 않았다. 당신이 얻는 것은 빈 줄에 블록 커서입니다.

5. 그런 다음 해당 블록 커서에서 심볼 코드를 복사하여 붙여 넣고 Enter 키를 누릅니다. 다음과 같은 내용이 표시됩니다.

   -[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

6. 블록 커서로 돌아가서 다른 기호를 붙여 넣을 수 있습니다.

첫 번째 비트를 다시 입력하지 않고 하나의 항목을 역 추적 할 수있어 시간을 절약 할 수 있습니다.

즐겨!

---

또한 상징적 충돌을 실행하기 전에 dsym, app bundle 및 crash log를 동일한 디렉토리에 넣습니다.

그런 다음 .profile에 정의 된이 함수를 사용하여 symbolicatecrash 실행을 단순화합니다.

function desym
{
    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

거기에 추가 된 주장이 도움이 될 수 있습니다.

다음 명령을 실행하여 스포트라이트가 dysm 파일을 "보는"지 확인할 수 있습니다.

mdfind 'com_apple_xcode_dsym_uuids = *'

디렉토리에있는 dsym을 찾으십시오.

참고 : 최신 Xcode부터 더 이상 개발자 디렉토리가 없습니다. 이 유틸리티는 여기에서 찾을 수 있습니다.

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers‌ions/A/Resources/symbolicatecrash

---

xcode 6.1.1에 대한 간단하고 업데이트 된 답변.

단계

1. Xcode> 창> 장치.

2. DEVICES 섹션의 장치 목록에서 장치를 선택하십시오.

3. View Device Logs (장치 로그보기)를 선택하십시오.

4. All Logs (모든 로그) 섹션에서 보고서를 직접 끌어다 놓을 수 있습니다.

5. Xcode는 자동으로 충돌 보고서를 상징합니다.

6. 충돌 보고서에 언급 된 날짜 / 시간과 날짜 / 시간을 일치시켜 Symbolicated 충돌 보고서를 찾을 수 있습니다.

---

지금은 몇 년 동안 앱을 개발했지만 이진 파일을 디버깅하는 것은 처음이었고 모든 파일이 어디에 있는지 알아내는 완전한 NOOB처럼 느껴졌습니다. * .app * .dSYM 및 크래쉬 로그는 어디에 있습니까? 이해하기 위해 여러 게시물을 읽어야했습니다. 그림은 천 단어의 가치가 있으며이 게시물이 앞으로 다른 사람에게 도움이되기를 바랍니다.

1- 먼저 itunesconnect로 이동하여 충돌 로그를 다운로드하십시오. 참고 : 대부분의 경우 "보고서를 표시하기 위해 너무 적은 보고서가 제출되었습니다"와 같은 메시지가 표시 될 수 있습니다. 기본적으로 충분하지 않은 사용자가 충돌 로그 보고서를 Apple에 제출 한 경우 해당 시점에서 많은 작업을 수행 할 수 없습니다.

2- 이제 바이너리를 Apple에 제출 한 후 코드를 변경하지 않은 경우 해당 프로젝트에 대해 Xcode를 시작하고 Product-> Archive를 다시 수행하십시오. 그렇지 않으면 최신 제출 바이너리를 찾아 마우스 오른쪽 버튼으로 클릭하십시오.

---

Xcode 4.2.1에서 Organizer 를 연 다음 Library / Device Logs 로 이동 하여 .crash 파일을 충돌 로그 목록으로 드래그하십시오. 몇 초 후에 그것은 당신을 위해 상징 될 것입니다.

원래 빌드가 아카이브 된 것과 동일한 Xcode 인스턴스를 사용해야합니다 (즉, 빌드의 아카이브가 Organizer에 있어야 함 ).

---

Xcode 4를 사용하면 작업이 훨씬 간단 해집니다.

• 오픈 오거나이저 ,
• 라이브러리를 클릭하십시오 | 왼쪽 열의 장치 로그
• click on "Import" button on the bottom of the screen...

and voilà. The log file is imported and Symbolized automatically for you. Provided you Archived the build using Xcode -> Product -> Archive first.

---

The magical Xcode Organizer isn't that magical about symbolicating my app. I got no symbols at all for the crash reports that I got back from Apple from a failed app submission.

I tried using the command-line, putting the crash report in the same folder as the .app file (that I submitted to the store) and the .dSYM file:

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

This only provided symbols for my app and not the core foundation code, but it was better than the number dump that Organizer is giving me and was enough for me to find and fix the crash that my app had. If anyone knows how to extend this to get Foundation symbols it would be appreciated.

---

In my case, I was dragging crash reports directly from Mail to the Organizer. For some reason, that prevented the crash reports from getting symbolicated (I'd love to know why).

Copying the crash reports to the Desktop first, and then dragging them from there to the Organizer got them symbolicated properly.

Very specific case, I know. But thought I'd share just in case.

---

Here's another issue I have with symbolicatecrash – it won't work with Apps that have spaces in their bundle (i.e. 'Test App.app'). Note I don't think you can have spaces in their name when submitting so you should remove these anyway, but if you already have crashes that need analysing, patch symbolicatecrash (4.3 GM) as such:

240c240
<         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
>         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
<             my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
>             my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

---

For those using Airbrake, there's a solid response above but it wouldn't work for me without tweaking:

Works for some memory addresses but not others, not sure why...

• Create new dir on desktop or wherever
• Find archive in question in Xcode organizer
• Double tap to reveal in finder
• Double tap to show bundle contents
• Copy .dSYM file and .app file into new dir
• cd into new dir
• Run this command: atos -arch armv7 -o 'Vimeo.app'/'Vimeo'
• Terminal will enter an interactive move
• Paste in memory address and hit enter, it will output method name and line number
• Alternatively, enter this command: atos -arch armv7 -o 'Vimeo.app'/'Vimeo' To get info for one address only

---

The combination that worked for me was:

1. Copy the dSYM file into the directory where the crash report was
2. Unzip the ipa file containing the app ('unzip MyApp.ipa')
3. Copy the application binary from the resulting exploded payload into the same folder as the crash report and symbol file (Something like "MyApp.app/MyApp")
4. Import or Re-symbolicate the crash report from within Xcode's organizer

Using atos I wasn't able to resolve the correct symbol information with the addresses and offsets that were in the crash report. When I did this, I see something more meaningful, and it seems to be a legitimate stack trace.

---

I had to do a lot of hacking of the symbolicatecrash script to get it to run properly.

As far as I can tell, symbolicatecrash right now requires the .app to be in the same directory as the .dsym. It will use the .dsym to locate the .app, but it won't use the dsym to find the symbols.

You should make a copy of your symbolicatecrash before attempting these patches which will make it look in the dsym:

Around line 212 in the getSymbolPathFor_dsymUuid function

212     my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

Around line 265 in the matchesUUID function

265             return 1;

---

This is simple, after searching a lot i found clear steps to symbolicate whole crash log file.

• copy .app , crash_report and DSYM files in a folder.
• connect the device with xcode
• Then go to window -> select devices -> view device logs
• Then select this device, delete all logs .
• drag and drop your crash on device log section . it will automatically symbolicate the crash . just right click on report and export it .

happy coding,
Riyaz

---

I prefer a script that will symbolicate all my crash logs.

Preconditions

Create a folder and put there 4 things:

1. symbolicatecrash perl script - there are many SO answers that tells it's location

2. The archive of the build that match the crashes (from Xcode Organizer. simple as Show in Finder and copy) [I don't sure this is necessery]

3. All the xccrashpoint packages - (from Xcode Organizer. Show in Finder, you may copy all the packages in the directory, or the single xccrashpoint you would like to symbolicate)

4. Add that short script to the directory:

   #!/bin/sh
   
   echo "cleaning old crashes from directory"
   rm -P *.crash
   rm -P *.xccrashpoint
   rm -r allCrashes
   echo "removed!"
   echo ""
   echo "--- START ---"
   echo ""
   
   mkdir allCrashes
   mkdir symboledCrashes
   find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \;
   
   cd allCrashes
   for crash in *.crash; do
       ../symbolicatecrash $crash > ../symboledCrashes/V$crash
   done
   cd ..
   
   echo ""
   echo "--- DONE ---"
   echo ""
   

The Script

When you run the script, you'll get 2 directories.

1. allCrashes - all the crashes from all the xccrashpoint will be there.

2. symboledCrashes - the same crashes but now with all the symbols.

3. you DON'T need to clean the directory from old crashes before running the script. it will clean automatically. good luck!

---

In order to symbolicate crashes, Spotlight must be able to find the .dSYM file that was generated at the same time the binary you submitted to Apple was. Since it contains the symbol information, you will be out of luck if it isn't available.

---

I got a bit grumpy about the fact nothing here seems to "just work" so I did some investigating and the result is:

Set up: QuincyKit back end that receives reports. No symbolication set up as I couldn't even begin to figure out what they were suggesting I do to make it work.

The fix: download crash reports from the server online. They're called 'crash' and by default go into the ~/Downloads/ folder. With that in mind, this script will "do the right thing" and the crash reports will go into Xcode (Organizer, device logs) and symbolication will be done.

The script:

#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode

if [ ! -e ~/Downloads/crash ]; then 
   echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
   exit 1
fi

cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx

datestr=`date "+%Y-%m-%d-%H%M%S"`

mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

Things can be automated to where you can drag and drop in Xcode Organizer by doing two things if you do use QuincyKit/PLCR.

Firstly, you have to edit the remote script admin/actionapi.php ~line 202. It doesn't seem to get the timestamp right, so the file ends up with the name 'crash' which Xcode doesn't recognize (it wants something dot crash):

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

Secondly, in the iOS side in QuincyKit BWCrashReportTextFormatter.m ~line 176, change @"[TODO]" to @"TODO" to get around the bad characters.

---

atos is being deprecated so if you are running OSX 10.9 or later you may need to run

xcrun atos

Warning: /usr/bin/atos is moving and will be removed from a future OS X release. It is now available in the Xcode developer tools to be invoked via: xcrun atos

---

I like to use Textwrangler to pinpoint errors in an original app upload binary rejection. (The crash data will be found in your itunesConnect account.) Using Sachin's method above I copy the original.crash to TextWrangler, then copy the symbolicatecrash file I've created to another TextWrangler file. Comparing the two files pinpoints differences. The symbolicatecrash file will have differences which point out the file and line number of problems.

---

I found out most of proposed alternatives did not work in latest XCode (tested with Xcode 10). For example, I had no luck drag-dropping .crash logs in Xcode -> Organizer -> Device logs -view.

I recommend using Symbolicator tool https://github.com/agentsim/Symbolicator

• Git clone Symbolicator repository and compile and run with Xcode
• Copy .crash file (ascii file, with stack trace in begging of file) and .xarchive of crashing release to same temporarly folder
• Drag and drop .crash file to Symbolicator icon in Dock
• In 5-30 secs symbolicated crash file is produced in same folder as .crash and .xarchive are

---

We use Google Crashlytics to supervise crash logs, the feeling is very timely and convenient to use.

Document links： https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

All about Missing dSYMs Fabric includes a tool to automatically upload your project’s dSYM. The tool is executed through the /run script, which is added to your Run Script Build Phase during the onboarding process. There can be certain situations however, when dSYM uploads fail because of unique project configurations or if you’re using Bitcode in your app. When an upload fails, Crashlytics isn’t able to symbolicate and display crashes, and a “Missing dSYM” alert will appear on your Fabric dashboard.

Missing dSYMs can be manually uploaded following the steps outlined below.

Note: As an alternative to the automated dSYM upload tool, Fabric provides a command-line tool (upload-symbols)) that can be manually configured to run as part of your project’s build process. See the upload-symbols section below for configuration instructions.

...

참고 URL : https://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports