iOS 충돌 보고서 : atos가 예상대로 작동하지 않음

iOS 충돌 보고서 : atos가 예상대로 작동하지 않음

---

Apple에서 제공 한 충돌 보고서를보고 있습니다.

Hardware Model:      iPhone4,1
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-11-18 16:03:44.951 -0600
OS Version:      iOS 6.0.1 (10A523)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x51fe5264
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x352925b0 objc_msgSend + 16
1   MYAPP                           0x0006573a -[MyViewController(Images) didReceiveImage:context:etag:expires:] + 42
2   MYAPP                           0x0004fb26 -[MyImageTask didReceiveImage:] + 98
3   Foundation                      0x361ac8e8 __NSThreadPerformPerform
4   CoreFoundation                  0x3b37d680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
5   CoreFoundation                  0x3b37cee4 __CFRunLoopDoSources0
6   CoreFoundation                  0x3b37bcb2 __CFRunLoopRun
7   CoreFoundation                  0x3b2eeeb8 CFRunLoopRunSpecific
8   CoreFoundation                  0x3b2eed44 CFRunLoopRunInMode
9   GraphicsServices                0x396bc2e6 GSEventRunModal
10  UIKit                           0x3452e2f4 UIApplicationMain
11  MYAPP                           0x0004934a main + 70
12  MYAPP                           0x000492fc start + 36

재미있는 점은 atos를 사용하여 주소 위치 0x0006573a 및 0x0004fb26에 해당하는 코드 줄을 조회 할 때 완전히 다른 일치를 얻습니다. atos 출력은 크래시 로그 (MyViewController, MyImageTask)에 언급 된 것과 동일한 클래스에서 나온 것이 아닙니다. 대신 atos는 전혀 관련이없는 클래스에서 완전히 무해한 코드 줄을 가리 킵니다. Apple에 제출 한 정확한 dSYM 및 IPA로 작업하고 있음을 다시 확인했습니다.

내 atos 명령

/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26

/ usr / bin / atos 및 armv7s와 동일한 결과입니다.

다른 사람이이 문제를 경험 한 적이 있습니까? 조언 해 주시겠습니까? 감사.

---

atos와 함께 사용할 주소를 계산해야합니다. 스택 트레이스에있는 주소 만 사용할 수는 없습니다.

symbol address = slide + stack address - load address

1. slide값의 값 vmaddr에서이 LC_SEGMENT cmd(주로이있다 0x1000). 그것을 얻으려면 다음을 실행하십시오.

   otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"
   

   ARCHITECTURE충돌 보고서에 표시되는 실제 아키텍처로 교체하십시오 ( 예 : armv7. APP_BUNDLE/APP_EXECUTABLE실제 실행 파일의 경로로 바꿉니다 .

2. 은 stack address충돌 보고서에서 16 진수 값입니다.

3. load address이 될 수는에서 보여주는 첫 번째 주소입니다 Binary Images눈앞 실행 파일이 포함 된 행의에 절을 참조하십시오. (보통 첫 번째 항목).

과거에는의 값 이이 slide값과 같았 기 때문에 load address항상 효과가있었습니다. 그러나 Apple은 iOS 4.3 (다른 변형)부터 주소 공간 레이아웃 무작위 화를 도입했기 때문에 보안상의 이유로 앱로드 주소가 무작위 화됩니다.

---

더 간단한 대안 : atos -l플래그를 사용 하여 수학을 수행 할 수 있습니다.

기호화하려는 충돌 로그에 다음 줄이 있다고 가정합니다.

5   MyApp                   0x0044e89a 0x29000 + 4348058

첫 번째 16 진수는 스택 주소이고 두 번째 16 진수는로드 주소입니다. 마지막 번호는 무시할 수 있습니다. 슬라이드 주소에 대해서도 걱정할 필요가 없습니다.

상징화하려면 다음을 수행하십시오.

atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a

MyApp.app/MyApp 파일을 찾을 수없는 경우 '.ipa'파일의 이름을 '.zip'으로 바꾸고 압축을 풀면 Payload 폴더에 있습니다.

사용할 아키텍처 (예 : armv7 또는 armv7s)를 잘 모르는 경우 충돌 파일의 '바이너리 이미지'부분으로 스크롤하면 찾을 수 있습니다.

건배

---

dwarfdump를 사용하기 만하면됩니다.

dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'

계산을 전혀 할 필요가 없습니다.

(From Get symbol by address (symbolicating binary, iOS build)).

---

For whom that certain times doesn't have the value for Load Address like this:

Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: (
    0   CoreFoundation                      0x2c3084b7 <redacted> + 150
    1   libobjc.A.dylib                     0x39abec8b objc_exception_throw + 38
    2   CoreFoundation                      0x2c21cc35 CFRunLoopRemoveTimer + 0
    3   AppName                             0x0005a7db AppName + 272347  

I've created a simple bash to help me debug:

#! /bin/bash
read -p "[Path] [App Name] [Stack Address] [DecimalSum] " path appName stackAddress decimalSum
loadAddress=`echo "obase=16;ibase=10;$((stackAddress-decimalSum))" | bc`
atos -o $path/Payload/$appName.app/$appName -l $loadAddress $stackAddress -arch armv7

It just reads the path for the app, the app name, the stack address, and the value after "+" signal (the decimal value) and then find the value for load address to run atos command.

참고URL : https://stackoverflow.com/questions/13574933/ios-crash-reports-atos-not-working-as-expected