symbolicate를 사용하지 않은 상태에서 충돌 로그 분석

최근 애플의 앱 심사에서 맥OS용 앱을 제출했지만 안타깝게도 앱이 붕괴된 것 같아 붕괴 로그를 보냈다.정말 처리하기 어려워요. 많은 시도를 한 후에 순조로운 결과를 내고 싶어요.

개요

충돌 로그 분석 준비(.crash 파일)

충돌 로그를 제시한 상황에서 이 프로그램이 붕괴되었을 때의 원인 파일과 줄 번호를 얻습니다

준비

이해하기 쉽도록 어디서든 해석용 디렉터리를 만들 수 있다(이번 가설은crash라는 디렉터리를 만들었다).

iTunes Connect에서 충돌 로그를 다운로드하여 crash 디렉터리에 넣습니다.

다음은 Xcode에서 붕괴된 응용 프로그램(제출된 버전)을 발굴합니다.

창에서 Organizer를 엽니다.

Archive 화면이 나타나므로 자신이 제출한 버전을 선택합니다.

찾기에 표시됩니다.

패키지의 내용을 표시하고 Products/Applications/의 자신의 응용 프로그램을crash 디렉터리에 삽입합니다.

붕괴 로그를 열고 이렇게 쓴 부분을 찾습니다.(주소가 가득한 곳)
그 중에서 자신의 응용 프로그램의 식별자가 있기 때문에 사용한 두 개의 주소입니다.

마지막으로 다음 명령을 수행합니다.터미널에서 작업합니다.crash 디렉터리로 이동해서 실행하십시오.

atos -o <アプリ名>.app/Contents/MacOS/<アプリ名> -arch x86_64 -l <短い方のアドレス> <長い方のアドレス>

하면, 만약, 만약...

atos -o Welemfine.app/Contents/MacOS/Welemfine -arch x86_64 -l 0x102abf000 0x0000000102ac2878

하계.

실행 결과

WeatherViewController.swift의 73 행(NSCollectionView의 콜백 함수 내)에서 충돌합니다.디버깅...!!!

총결산

사실symbolicate로 잘 해석하면 좋겠지만 붕괴 보고서의 버전이 적합하지 않으면 오류가 발생하기 때문에 일반적인 방법으로는 안 된다.또 즉각적인 대응이 필요해 이런 수법을 썼다.또한 iOS의 충돌 로그 해석에 대한 정보가 비교적 많다.

참고 자료