동맹 붕괴 통계에 따라 문제를 찾는 방법

한 번은 우맹통계표를 보러 갔는데 기록된 많은 붕괴통계가 잘 보이지 않았고 구체적인 붕괴 코드도 보이지 않았다. 그래서 인터넷에서 붕괴 코드를 포지셔닝하는 방법을 찾았다. 다음은 내가 생각하는 비교적 좋은 방법이다.
충돌 레코드:

-[__NSArrayM overRect]: unrecognized selector sent to instance 0x1742528a0
(null)
((
    0   CoreFoundation                      0x00000001888aaff0  + 148
    1   libobjc.A.dylib                     0x000000018730c538 objc_exception_throw + 56
    2   CoreFoundation                      0x00000001888b1ef4  + 0
    3   CoreFoundation                      0x00000001888aef4c  + 916
    4   CoreFoundation                      0x00000001887aad2c _CF_forwarding_prep_0 + 92
    5   Butler                              0x100036f0c Butler + 225036
    6   AVFoundation                        0x00000001902f3310  + 308
    7   AVFoundation                        0x00000001902f314c  + 100
    8   CoreMedia                           0x000000018b1c8f68  + 260
    9   CoreMedia                           0x000000018b1e7e9c  + 224
    10  libdispatch.dylib                   0x00000001877629a0  + 16
    11  libdispatch.dylib                   0x000000018776f604  + 448
    12  libdispatch.dylib                   0x000000018777bc1c  + 204
    13  libdispatch.dylib                   0x00000001877648a0  + 804
    14  libdispatch.dylib                   0x0000000187770964  + 560
    15  libdispatch.dylib                   0x00000001877662cc  + 884
    16  libdispatch.dylib                   0x0000000187770964  + 560
    17  libdispatch.dylib                   0x00000001877662cc  + 884
    18  libdispatch.dylib                   0x0000000187771950  + 256
    19  libdispatch.dylib                   0x0000000187778170  + 760
    20  libsystem_pthread.dylib             0x000000018796b08c _pthread_wqthread + 772
    21  libsystem_pthread.dylib             0x000000018796ad7c start_wqthread + 4
)

dSYM UUID: 7170B52B-0F44-32E0-B89A-C900C55AB3BE
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: Butler
Base Address: 0x00000001000cc000

이와 같은 붕괴 기록은 반드시 나타나는 것이 아니기 때문에 일시적으로 붕괴된 곳을 찾기 어렵다. 다음은 붕괴된 코드를 한 걸음 한 걸음 찾아보자.
첫 번째 단계: 코드를 업로드할 때 사용했던 DYSM 파일을 찾습니다. 이 파일은 보통 있습니다.xcarchive 파일에서오른쪽 XXX.xcarchive 파일을 터미널 도구로 엽니다.2단계: XXX로 들어갑니다.xcarchive 파일의 DWARF 디렉토리(아래는 디렉토리)

~/Butler.xcarchive/dSYMs/XXX.app.dSYM/Contents/Resources/DWARF

세 번째 단계: 그리고 다음 명령을 집행한다.이 메모리 주소가 역컴파일된 원본 줄을 볼 수 있습니다.

//   YYYY  CPUType（     arm64，           ）,XXX      Binary Image      ，           
atos -arch YYYY -o XXX 0x1153b9

실행 결과:

➜  DWARF atos -arch arm64 -o Butler 0x100036f0c  
-[XJHPlateIDScanViewController captureOutput:didOutputSampleBuffer:fromConnection:] (in Butler) (XJHPlateIDScanViewController.mm:154)

이렇게 하면 붕괴된 코드를 볼 수 있다!!!
마지막으로 주의: 만약에 위치가 UmengSignalHandler라면 이것은 오류가 아니라 crash를 포착하는 방법입니다. 그 자체가 crash를 일으키지 않습니다. crash가 발생할 때 포착하고 crash log의 UmengSignalHandler 부분을 무시하면 됩니다.
참조 링크:http://blog.csdn.net/smking/article/details/9342899