장애 패턴 사전

치명 앱 크래시 (자바/코틀린 예외) java-crash

찾는 문구

태그가 정확히 AndroidRuntime이고, 메시지 첫 줄이 FATAL EXCEPTION으로 시작(단, IN SYSTEM PROCESS가 붙은 것은 다음 규칙)

대상 표시

같은 기록 안의 Process: 패키지명, 줄. 줄마다 시각이 달라 합쳐지지 않았다면 바로 뒤 3줄 안의 같은 PID·태그 줄에서 찾고, 없으면 PID

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.example.tv, PID: 1102
E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method ...
E AndroidRuntime: 	at com.example.tv.ui.ChannelListAdapter.onBindViewHolder(ChannelListAdapter.java:88)

뜻

앱 코드에서 처리되지 않은 예외가 발생해 프로세스가 종료됐습니다. main은 예외가 난 스레드 이름입니다. 메인 스레드가 아닌 작업 스레드여도 처리되지 않은 예외라면 앱 전체가 종료됩니다.

다음에 확인할 것

1. 예외 이름(NullPointerException 등)과 메시지 — 무엇이 잘못됐는지
2. 스택트레이스에서 가장 위에 있는 앱 패키지의 줄 — 어디서 났는지(파일명.java:줄번호)
3. Caused by: 줄이 있다면 맨 아래의 것이 근본 원인인 경우가 많습니다
4. 직후의 프로세스 종료 기록과 Start proc 기록 — 앱이 자동으로 다시 떴는지, 새 PID는 무엇인지

잘못 잡거나 놓치는 경우

앱이 예외를 직접 잡아 Log.e로만 남기면 크래시가 아니므로 이 규칙에 걸리지 않습니다(일반 오류로 집계됨). 반대로 크래시 리포팅 라이브러리가 예외를 가로챈 뒤 다시 던지면 같은 크래시가 두 번 기록될 수 있습니다.

치명 시스템 프로세스 크래시 system-crash

찾는 문구

태그 AndroidRuntime + 첫 줄에 FATAL EXCEPTION IN SYSTEM PROCESS

대상 표시

항상 system_server

E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: android.ui

뜻

앱이 아니라 안드로이드 시스템 서버(system_server)가 죽었습니다. 시스템 서버가 재시작되면 화면이 부팅 애니메이션으로 돌아가거나 모든 앱이 한꺼번에 종료되는 "소프트 리부트"가 일어납니다.

다음에 확인할 것

예외의 스택트레이스(대개 com.android.server 패키지)와 직전 수십 초의 시스템 로그. 제조사가 추가한 시스템 서비스에서 나는 경우가 많아, 셋톱박스라면 펌웨어 버전과 함께 제조사에 전달할 대상입니다.

잘못 잡거나 놓치는 경우

시스템 서버가 죽은 직후에는 logcat 데몬이나 adb 연결도 끊길 수 있어, 수집 방식에 따라 이 줄 자체가 파일에 남지 않을 수 있습니다.

치명 응답 없음 (ANR) anr

찾는 문구

메시지 첫 줄이 ANR in + 공백 없는 문자열로 시작. 태그는 따지지 않습니다(버전·제조사마다 태그가 조금씩 달라서)

대상 표시

ANR in 뒤의 패키지명

E ActivityManager: ANR in com.example.tv (com.example.tv/.MainActivity)
E ActivityManager: PID: 1102
E ActivityManager: Reason: Input dispatching timed out (...)

뜻

앱의 메인 스레드가 정해진 시간 안에 응답하지 못했습니다. 입력 이벤트(리모컨 키 등)는 기본 5초가 기준이고, 브로드캐스트·서비스는 기준이 더 깁니다. 종류별 시간은 ANR 분석 글에 정리했습니다.

다음에 확인할 것

1. Reason: 줄 — 입력·브로드캐스트·서비스 중 무엇이 늦었는지
2. 바로 뒤의 CPU 사용률 요약 — 기기 전체가 바빴는지, 해당 앱만 멈췄는지
3. ANR 직전 같은 PID의 기록 — 디스크·네트워크 작업이나 잠금 대기 흔적
4. 메인 스레드 스택이 담긴 traces 파일(adb bugreport에 포함)

잘못 잡거나 놓치는 경우

앱이 자체적으로 "ANR in ..."으로 시작하는 문장을 남기면 잡힐 수 있습니다(드묾). 메시지 중간에 "ANR"이 들어간 일반 오류는 잡지 않습니다.

치명 네이티브 크래시 (Fatal signal) native-crash

찾는 문구

메시지 첫 줄이 Fatal signal 숫자 (SIG대문자)로 시작. 보통 태그 libc, 레벨 F

대상 표시

줄 끝의 pid N (프로세스명). 없으면(옛 버전) in tid N (스레드명)의 스레드명. 상세에 시그널 이름(SIGSEGV 등)

F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 2250 (CodecLooper), pid 2201 (com.example.player)

뜻

C/C++로 된 코드(코덱, 드라이버, 게임 엔진, 앱의 네이티브 라이브러리)가 잘못된 메모리에 접근했거나 스스로 중단했습니다. SIGSEGV는 잘못된 주소 접근, SIGABRT는 의도적 중단(assert 실패 등)입니다. fault addr 0x0은 널 포인터 접근을 뜻합니다.

다음에 확인할 것

이어지는 DEBUG(버전에 따라 crash_dump) 태그의 backtrace:와 #00 pc ... 줄, 그리고 tombstone 파일. 읽는 법은 네이티브 크래시 글에 있습니다.

잘못 잡거나 놓치는 경우

디버거가 붙어 있거나 의도적으로 시그널을 보낸 경우에도 기록될 수 있습니다. 커널 패닉처럼 기기 전체가 멈추는 경우에는 logcat에 남지 않습니다.

치명 시스템 워치독 watchdog

찾는 문구

메시지 어디든 WATCHDOG KILLING SYSTEM PROCESS

대상 표시

항상 system_server

W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in handler on main thread (main)

뜻

시스템 서버의 핵심 스레드가 오랫동안 멈춰 있어 워치독이 시스템 서버를 강제로 재시작했습니다. 사용자에게는 화면이 한동안 멈췄다가 재부팅되는 것처럼 보입니다.

다음에 확인할 것

콜론 뒤의 설명(어느 스레드·핸들러가 막혔는지)과 그 전 1분가량의 기록. 같은 시각의 디스크·네트워크 장애나 잠금 경합 흔적을 찾습니다.

잘못 잡거나 놓치는 경우

워치독이 경고만 남기고 재시작까지 가지 않은 경우(문구가 다름)는 잡지 않습니다.

주의 메모리 부족 예외 (OutOfMemoryError) oom

찾는 문구

메시지(여러 줄 전체) 어디든 java.lang.OutOfMemoryError

대상 표시

태그와 PID

E AndroidRuntime: java.lang.OutOfMemoryError: Failed to allocate a 8388620 byte allocation with 4194304 free bytes

뜻

앱 하나에 허용된 자바 힙 한도를 넘었습니다. 기기 전체 메모리가 부족한 것과는 다른 문제입니다(그쪽은 강제 종료로 나타남).

다음에 확인할 것

할당하려던 크기(큰 이미지·버퍼인지), 같은 앱에서 이 예외가 시간이 지날수록 잦아지는지(누수 의심). 이 예외가 처리되지 않으면 바로 앞이나 뒤에 앱 크래시가 함께 잡힙니다 — 한 기록이 두 규칙에 동시에 걸리지는 않으므로, 같은 시각의 앱 크래시를 함께 보세요.

잘못 잡거나 놓치는 경우

ART 런타임이 남기는 Throwing OutOfMemoryError처럼 패키지 접두사가 없는 문구는 잡지 않습니다(같은 사건이 두 번 세어지지 않도록).

주의 메모리 확보용 강제 종료 (lmkd) lmk-kill

찾는 문구

태그가 lowmemorykiller 또는 lmkd이고 첫 줄이 Kill ' 또는 Killing '로 시작

대상 표시

작은따옴표 안의 프로세스명

I lowmemorykiller: Kill 'com.example.epg' (1650), uid 10031, oom_score_adj 900 to free 48212kB rss, 2048kB swap

뜻

기기 전체 메모리가 부족해 시스템이 우선순위 낮은 프로세스를 강제로 종료했습니다. 앱 입장에서는 크래시 기록 없이 "그냥 사라진" 것처럼 보입니다. oom_score_adj가 클수록 종료 우선순위가 높은(덜 중요한) 프로세스입니다.

다음에 확인할 것

강제 종료된 프로세스의 oom_score_adj(900 이상이면 백그라운드 캐시 앱, 0에 가까우면 화면에 보이던 앱), 짧은 시간에 몇 개가 연달아 종료됐는지, 그때 메모리를 많이 쓰던 앱이 무엇인지. 자세한 내용은 메모리 강제 종료 글.

잘못 잡거나 놓치는 경우

안드로이드 버전·제조사에 따라 이 기록이 커널 로그(dmesg)에만 남고 logcat에는 없을 수 있습니다. 그 경우 이 규칙으로는 찾을 수 없습니다.

참고 네이티브 크래시 덤프 저장 tombstone

찾는 문구

메시지 어디든 Tombstone written to:

대상 표시

저장된 파일 경로

F DEBUG   : Tombstone written to: /data/tombstones/tombstone_02

뜻

네이티브 크래시의 전체 정보(레지스터, 모든 스레드의 백트레이스, 메모리 맵)가 기기에 파일로 저장됐다는 기록입니다. 그 자체는 장애가 아니라 네이티브 크래시의 후속 기록입니다.

다음에 확인할 것

경로의 파일을 확보해 두세요. 일반 사용자 빌드에서는 /data/tombstones를 직접 읽을 수 없는 경우가 많아 adb bugreport로 받는 것이 일반적입니다. 파일 번호는 순환 재사용되므로 늦게 받으면 덮어써질 수 있습니다.

잘못 잡거나 놓치는 경우

버전에 따라 문구가 다르거나 logcat에 남지 않을 수 있습니다.

참고 프로세스 종료 기록 proc-died

찾는 문구

태그가 ActivityManager로 시작하고 첫 줄이 Process 이름 (pid 숫자) has died로 시작

대상 표시

프로세스명

I ActivityManager: Process com.example.epg (pid 1650) has died: cch+5 CEM

뜻

시스템이 프로세스가 사라진 것을 확인했다는 기록입니다. 원인은 크래시, 강제 종료, 사용자의 종료 등 무엇이든 될 수 있습니다. 그래서 단독으로는 "참고"이고, 바로 앞에 크래시나 강제 종료 기록이 있는지로 원인을 구분합니다. 콜론 뒤(fg TOP, cch+5 등)는 죽을 당시의 프로세스 상태 요약으로, fg/TOP이면 화면에 보이던 앱이었다는 뜻입니다(표기는 버전마다 다름).

다음에 확인할 것

같은 이름이 앞에 FATAL EXCEPTION도 Kill '도 없이 죽었다면, 앱이 스스로 종료했거나 다른 경로(네이티브 크래시, 외부 kill)일 수 있습니다. 앞쪽 수 초의 기록을 확인하세요.

잘못 잡거나 놓치는 경우

다른 태그가 남긴 비슷한 문장은 잡지 않습니다. 앱 업데이트·재설치로 인한 종료도 같은 문구로 남습니다.

참고 프레임 누락 (메인 스레드 지연) skipped-frames

찾는 문구

태그 Choreographer + 첫 줄이 Skipped 숫자 frames로 시작

대상 표시

PID, 상세에 누락된 프레임 수

I Choreographer: Skipped 48 frames!  The application may be doing too much work on its main thread.

뜻

앱의 메인 스레드가 바빠 화면 갱신을 건너뛰었습니다. 60Hz 기준 48프레임이면 약 0.8초 동안 화면이 멈춘 셈입니다. ANR까지 가지 않은 "버벅임"의 흔적이며, 같은 PID에서 자주 나오고 점점 커진다면 ANR의 전조일 수 있습니다.

다음에 확인할 것

프레임 수의 크기와 빈도, 같은 시각의 디스크·네트워크 작업 기록.

잘못 잡거나 놓치는 경우

앱 시작 직후 한 번 나오는 작은 값은 흔하며 대개 무시해도 됩니다. 이 기록은 일정 프레임 수 이상일 때만 남으므로 작은 끊김은 기록되지 않습니다.

참고 중복 압축 (chatty) chatty

찾는 문구

태그 chatty + identical 숫자 line(s)

대상 표시

uid=1000(system)의 괄호 안 이름, 상세에 생략된 줄 수

I chatty  : uid=1000(system) Binder:512_5 identical 37 lines

뜻

같은 내용이 너무 자주 반복돼 logcat이 37줄을 생략하고 이 한 줄만 남겼습니다. 장애는 아니지만, 집계된 오류 건수가 실제보다 적을 수 있다는 경고입니다.

다음에 확인할 것

바로 앞에 남아 있는 원래 줄이 무엇인지. 정확한 건수가 필요하다면 버퍼 크기만 늘려서는 해결되지 않습니다. adb logcat -P로 특정 UID를 압축 예외 목록에 두는 방법이 있지만 기기·버전마다 지원 여부가 달라, 먼저 adb logcat -p로 현재 설정을 확인하세요.

잘못 잡거나 놓치는 경우

최신 안드로이드 버전에서는 chatty 압축 동작이 바뀌어 이 줄이 거의 나오지 않을 수 있습니다.