ANDROID · LLDB · TOMBSTONE · ART

Android 오류 분석: LLDB·tombstone·ANR 자료를 구분합니다

실행 중인 프로세스의 상태와 종료 뒤 남은 기록은 다른 증거입니다. 먼저 빌드와 권한, 관측하려는 실행 계층을 맞춥니다.

GDB 안내를 현재의 기본 경로로 옮겨 적지 않습니다

현재 AOSP의 네이티브 플랫폼 디버깅 안내는 LLDB를 사용하며 GDB는 지원·제공하지 않는다고 명시합니다. 앱의 Android Studio 디버깅과 플랫폼의 lldbclient.py 절차도 적용 대상이 다릅니다. 오래된 GDB 자료에서 개념을 배우더라도 명령과 도구 배치는 대상 Android 버전에 맞춰 다시 확인해야 합니다.

앱은 debuggable 설정과 디버거 종류를, 시스템 프로세스는 기기 빌드와 허용된 root·디버깅 환경을 확인합니다. attach 실패를 해결하려고 제품의 SELinux나 보안 정책을 무조건 끄지 않습니다. 이 글은 장치에 연결하거나 보안 설정을 변경하지 않습니다.

AOSP의 LLDB 플랫폼 디버깅

심볼을 열기 전에 같은 빌드인지 확인합니다

ABI·Build ID·빌드 변형이 맞는 바이너리와 디버그 심볼을 준비합니다. 이름이 같은 라이브러리라도 다른 빌드의 심볼을 쓰면 함수와 줄 번호를 잘못 연결할 수 있습니다. 플랫폼 디버깅의 빌드 환경도 기기에 설치한 이미지와 일치해야 합니다.

tombstone의 signal, fault 주소, abort 메시지, 레지스터와 backtrace는 함께 읽습니다. libc의 abort나 메모리 함수가 마지막 프레임이라고 그 함수가 근본 원인인 것은 아닙니다. 앞선 메모리 손상이나 호출자의 잘못된 인자는 별도 재현과 추적이 필요합니다.

플랫폼 빌드와 심볼 일치 조건

네이티브 크래시 해석

Java·네이티브·커널의 스택은 같은 출력이 아닙니다

Java·Kotlin 상태는 관리 런타임 관점에서, C/C++ 상태는 네이티브 프레임과 심볼로 읽습니다. android-16.0.0_r1의 ART SignalCatcher는 SIGQUIT를 처리하며 DumpForSigQuit 결과를 출력 경로로 넘깁니다. 이 동작을 네이티브 크래시 한 건이나 커널 스택 전체와 동일시하지 않습니다.

분기와 관측 지점을 나눈 자체 개념도
  1. 살아 있는 실행 상태 → 허용된 디버거와 해당 계층의 스택

  2. 종료 당시 상태 → 같은 빌드의 tombstone·심볼 대조

  3. 응답 지연 → ANR 자료와 시간 정보의 상관관계

Android 16 ART의 SIGQUIT 처리

ANR 자료의 위치와 접근 조건도 버전에 묶입니다

공식 ANR 안내는 예전의 /data/anr/traces.txt와 최근의 /data/anr/anr_*를 구분하며 bugreport를 통한 수집도 설명합니다. 파일이 보이지 않는 경우에는 권한·빌드·자료 수집 방식을 먼저 확인합니다. 정해진 경로에 파일이 없다고 해서 ANR이 없었던 것은 아닙니다.

오류 기록에는 기기 빌드와 앱 버전, 재현 시각, PID·TID, 수집한 자료 종류, 심볼의 Build ID와 아직 확인하지 못한 부분을 남깁니다. 받은 자료의 원본 카드 이미지와 전체 영상은 이 글에서 검증하지 않았습니다.

ANR 자료 수집과 접근 조건