Mac에서 앱이 충돌하는 경우는 매우 드뭅니다. 하지만 충돌이 발생하면 문제를 추적하고 싶을 수 있습니다. 개발자라면 앱이 충돌하는 이유를 파악해야 합니다. macOS 충돌 보고서를 읽고 이해하기 어려운 용어들을 구분하는 방법을 소개합니다.
로압 스리유에스
충돌 보고서 열기
Mac에서 앱이 충돌하면 자동으로 충돌 보고서가 생성됩니다. 충돌 후 "[앱]이 예기치 않게 중지되었습니다."라는 경고 대화 상자와 함께 충돌 보고서가 나타납니다. 이 충돌 보고서는 "보고서..." 버튼을 클릭하면 이 창에서 바로 확인할 수 있습니다. 콘솔 앱에서도 충돌 보고서를 확인할 수 있습니다.
1. Spotlight에 "Console"을 입력하여 콘솔 앱을 열거나 "응용 프로그램 -> 유틸리티 -> Console.app"으로 이동합니다.
2. 왼쪽 메뉴에서 "사용자 보고서"를 클릭한 다음, 확인하려는 충돌 보고서를 클릭합니다. 모든 파일은 ".crash"로 끝나며, 제목에 날짜와 충돌한 애플리케이션이 포함됩니다. 충돌 보고서의 세부 정보는 오른쪽 창에서 확인할 수 있습니다.
Mac OS 충돌 보고서 읽기
충돌 보고서를 처음부터 끝까지 살펴보겠습니다.
무엇이 고장났나요?
충돌 보고서의 첫 번째 부분은 프로세스 또는 애플리케이션의 충돌 여부를 알려줍니다. 문제 해결사에서 가장 중요한 부분은 프로세스 이름입니다.
프로세스: aText [11473] 경로: /Applications/aText.app/Contents/MacOS/aText 식별자: com.trankynam.aText 버전: 2.19 (62) 코드 유형: X86-64 (네이티브) 상위 프로세스: ??? [1] 담당자: aText [11473] 사용자 ID: 501
실패는 언제 발생했나요?
두 번째 부분에서는 장애 발생 시점을 알려줍니다. 또한 시스템에 대한 정보도 제공합니다.
날짜/시간: 2018년 3월 15일 00:58:10.552 -0400 운영체제 버전: Mac OS 630000초 시스템 무결성 보호: 활성화됨
실패의 원인은 무엇인가?
다음 부분이 가장 중요합니다. 애플리케이션에서 발생하는 "예외 유형"은 충돌의 원인을 알려줍니다. 로그에는 충돌이 발생한 스레드(이 경우에는 스레드 0)도 기록됩니다.
충돌 스레드: 0 디스패치 큐: com.apple.main-thread 예외 유형: EXC_BAD_ACCESS (SIGSEGV) 예외 코드: 0x000040dedeadbec0의 KERN_INVALID_ADDRESS 예외 참고: EXC_CORPSE_NOTIFY 종료 신호: 세그멘테이션 오류: 11 종료 이유: 네임스페이스 SIGNAL, 코드 0xb 종료 프로세스: exc 핸들러 [0]
애플 리스트 몇 가지 일반적인 예외 유형 기술 문서에는 다음이 포함되어 있습니다.
잘못된 메모리 액세스(EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – 프로그램이 메모리에 잘못 액세스하거나 잘못된 주소를 사용하여 액세스하려고 합니다. 이 코드는 메모리 문제를 설명합니다.
비정상 종료(EXC_CRASH/SIGABRT) – 일반적으로 포착되지 않은 C++ 예외와 abort() 호출로 인해 비정상 종료가 발생합니다.
추적 트랩(EXC_BREAKPOINT/SIGTRAP) – SIGABRT와 유사하지만, 이 종료를 통해 연결된 디버거가 중단점에서 프로세스를 중단하고 오류를 추적할 수 있습니다.
불법적인 지시(EXC_BAD_INSTRUCTION / SIGILL) – 프로세스가 이해할 수 없거나 처리할 수 없는 지시를 발행했습니다.
종료(SIGQUIT) – 프로세스가 충분한 권한을 가진 다른 프로세스에 의해 종료되었습니다. 일반적으로 모니터링 프로세스는 오작동하는 프로세스를 종료합니다.
종료(SIGKILL) – 프로세스가 시스템 요청에 따라 종료되었습니다. 예외를 설명하는 종료 코드가 추가됩니다.
충돌 보고서에서 볼 수 있듯이, 애플리케이션이 할당되지 않은 메모리에 접근하려고 시도했습니다. 이는 애플리케이션의 프로그래밍 오류 또는 비정상적인 사용자 동작으로 인해 애플리케이션이 메모리를 잘못 할당했기 때문입니다.
오작동의 원인은 무엇입니까?
다음으로, 충돌 원인에 대한 역순 목록을 볼 수 있습니다. 스레드 0부터 시작하여 스레드별로 정렬되어 있습니다.
이 보고서에는 네 개의 열이 있습니다. 첫 번째 열은 0부터 시작하여 역순으로 이벤트 번호를 나타냅니다. 두 번째 열은 프로세스 ID입니다. 세 번째 열은 메모리에 있는 프로세스 주소입니다. 네 번째 열은 프로그램 작업 이름입니다.
이 "롤백"은 다소 혼란스러울 수 있습니다. "심볼릭" 방식으로, 일부 메모리 주소가 함수 이름이나 애플리케이션 작업으로 대체되었음을 의미합니다. 때로는 이 작업이 완전히 수행되지 않아 읽을 수 없는 메모리 주소가 보고서 전체에 흩어져 있는 경우가 있습니다.
위 충돌 보고서에서 확인할 수 있습니다. com.trankynam.aText는 기호 코드가 아닙니다. 완전한 기호 코드가 있더라도 백트레이스는 읽기 어려울 수 있습니다. 개발자가 애플리케이션 작업 및 이벤트에 대한 유용한 정보를 제공하는 경우도 있지만, 암호 주소나 숫자 코드인 경우도 있습니다. 기호 코드를 이해하면 무슨 일이 일어나고 있는지 이해할 수 있을 것입니다. 하지만 백트레이스를 이해하려면 가능한 한 애플리케이션을 직접 코딩해야 합니다.
결론: 도움이 되나요?
개발자라면 충돌 보고서를 읽는 것이 필수적입니다. 앱의 어느 부분에서 문제가 발생하고 그 이유가 무엇인지 파악하는 데 도움이 됩니다. 하지만 사용자라면 그다지 도움이 되지 않습니다. 하지만 지속적으로 충돌이 발생하는 경우, 충돌 보고서를 통해 문제를 해결하거나 개발자와 협력하여 문제를 해결할 수 있습니다. Google에서 유용한 오류 코드 해결책을 제공받거나, 정확한 정보와 함께 지원팀에 제출할 수도 있습니다. 자세한 내용을 알고 싶다면 다음에서 자세한 내용을 읽어보세요. Apple의 충돌에 대한 기술 노트.
