Mac에서 앱 충돌은 일반적으로 매우 드뭅니다. 그러나 이러한 일이 발생하면 원인을 추적할 수 있습니다. 그리고 개발자라면 앱이 충돌하는 이유를 이해해야 합니다. 다음은 macOS 충돌 보고서를 읽고 난해한 언어를 분류하는 방법입니다.
오류 보고서 열기
Mac에서 앱이 충돌하면 충돌 보고서가 자동으로 생성됩니다. 충돌 후 "[앱]이 예기치 않게 종료되었습니다.라는 경고 대화상자가 표시됩니다. " 그 충돌 보고서는 "보고 ..." 버튼을 클릭하여 해당 창에서 즉시 읽을 수 있습니다. 충돌 보고서는 콘솔 앱에서도 찾을 수 있습니다.
1. Spotlight에 "Console"을 입력하거나 "Application -> Utilities -> Console.app"으로 이동하여 콘솔 애플리케이션을 엽니다.
2. 왼쪽 메뉴에서 "사용자 보고서"를 클릭한 다음 보고 싶은 충돌 보고서를 클릭합니다. 이 모든 파일은 ".crash"로 끝나고 제목에 날짜와 충돌한 응용 프로그램을 포함합니다. 충돌 보고서의 세부 정보는 오른쪽 창에서 확인할 수 있습니다.
macOS 충돌 보고서 읽기
충돌 보고서를 위에서 아래로 탐색해 보겠습니다.
무엇이 다운되었나요?
충돌 보고서의 첫 번째 부분은 어떤 "프로세스" 또는 응용 프로그램이 충돌했는지 알려줍니다. 일반적인 문제 해결사에서 가장 중요한 부분은 프로세스 이름입니다.
Process: aText [11473] Path: /Applications/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Version: 2.19 (62) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: aText [11473] User ID: 501
언제 다운되었나요?
두 번째 부분은 충돌이 발생한 시간을 알려줍니다. 또한 시스템에 대한 약간의 정보도 제공합니다.
Date/Time: 2018-03-15 00:58:10.552 -0400 OS Version: Mac OS X 10.12.6 (16G1036) Report Version: 12 Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 seconds System Integrity Protection: enabled
비정상 종료의 원인은 무엇입니까?
다음 부분이 가장 빛을 발합니다. 응용 프로그램에서 제공하는 "예외 유형"은 충돌의 원인을 알려줍니다. 로그는 또한 어떤 스레드가 충돌했는지 보고합니다(이 경우 스레드 0).
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0]
Apple은 기술 문서에 몇 가지 일반적인 예외 유형을 나열합니다.
- 잘못된 메모리 액세스(
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) – 프로그램이 메모리에 잘못 액세스하거나 잘못된 주소로 액세스하려고 시도합니다. 메모리 문제를 설명하는 코드가 추가되었습니다. - 비정상 종료(
EXC_CRASH/SIGABRT) – 일반적으로 포착되지 않은 C++ 예외 및abort()호출 시 비정상적인 종료 - 트레이스 트랩(
EXC_BREAKPOINT) /SIGTRAP) – SIGABRT와 비슷하지만 이 종료는 연결된 디버거가 중단점에서 프로세스를 중단하고 오류를 추적할 수 있는 기회를 제공합니다. - 불법 명령(
EXC_BAD_INSTRUCTION/SIGILL) – 처리됨이 이해할 수 없거나 처리할 수 없는 명령을 발행했습니다. - 종료(
SIGQUIT) – 프로세스가 충분한 권한을 가진 다른 프로세스에 의해 종료되었습니다. 일반적으로 감시 프로세스는 오작동하는 프로세스를 종료합니다. - 사망(
SIGKILL) – 시스템의 요청에 따라 프로세스가 종료되었습니다. 예외를 설명하기 위해 종료 코드가 추가됩니다.
충돌 보고서에서 볼 수 있듯이 응용 프로그램은 매핑되지 않은 메모리에 액세스하려고 했습니다. 이는 응용 프로그램의 프로그래밍 오류 또는 응용 프로그램이 메모리를 잘못 매핑하게 하는 비정상적인 사용자 상태 때문입니다.
비정상 종료의 원인은 무엇입니까?
그 후 우리는 충돌로 이어지는 역 연대순 목록을 봅니다. 스레드 0부터 시작하여 스레드별로 정렬됩니다.
이 보고서에는 4개의 열이 있습니다. 첫 번째는 0부터 시작하여 역순으로 이벤트 번호를 보고합니다. 두 번째는 프로세스의 식별자입니다. 세 번째는 메모리에 있는 프로세스의 주소입니다. 네 번째는 프로그램의 작업 이름입니다.
이 "역추적"은 다소 당혹스러울 수 있습니다. "기호화"되어 메모리 주소 중 일부가 함수 이름 또는 응용 프로그램 작업으로 대체되었음을 의미합니다. 때로는 이 작업을 완전히 수행할 수 없어 읽을 수 없는 메모리 주소가 보고서 전체에 흩어져 있습니다.
위의 충돌 보고서에서 이를 확인할 수 있습니다. com.trankynam.aText 상징화되지 않습니다. 완전한 기호화를 사용하더라도 역추적을 읽기 어려울 수 있습니다. 때때로 개발자는 응용 프로그램 작업 및 이벤트에 대한 유용한 메모를 포함합니다. 다른 경우에는 수수께끼 같은 제목이나 숫자 코드입니다. 상징을 이해할 수 있다면 무슨 일이 일어나고 있는지 이해할 수 있을 것입니다. 그러나 역추적을 이해하려면 애플리케이션을 직접 코딩해야 하는 경우도 마찬가지입니다.
결론:유용한가요?
개발자라면 충돌 보고서를 읽는 것이 필수적입니다. 응용 프로그램의 어떤 부분이 충돌하고 그 이유를 이해하는 데 도움이 됩니다. 사용자라면 그다지 도움이 되지 않습니다. 그러나 지속적인 충돌이 있는 경우 충돌 보고서를 통해 문제를 해결하거나 개발자와 협력하여 문제를 해결할 수 있습니다. Google에 유용한 오류 코드를 받거나 올바른 정보로 기술 지원을 제공할 수 있습니다. 피투성이의 세부 사항을 원하시면 충돌에 대한 Apple의 기술 노트에서 모든 내용을 읽을 수 있습니다.