🧐 탐정 수사: 첫 번째 사례

개요

이번 퍼즐에서는 크래시가 발생하는 GPU 프로그램이 주어집니다. 소스 코드를 보지 않고 (cuda-gdb) 디버깅 도구만으로 문제를 찾아내야 합니다. 디버깅 스킬을 발휘해 미스터리를 풀어보세요!

사전 준비: Mojo GPU 디버깅의 핵심을 먼저 완료해서 CUDA-GDB 설정과 기본 디버깅 명령어를 익혀두세요. 아래 명령을 실행했는지 확인하세요:

pixi run -e nvidia setup-cuda-gdb

이 명령은 시스템의 CUDA 설치를 자동으로 감지하고 GPU 디버깅에 필요한 링크를 설정합니다.

핵심 개념

이번 디버깅 챌린지에서 배울 내용:

• 체계적인 디버깅: 오류 메시지를 단서 삼아 근본 원인 찾기
• 오류 분석: 크래시 메시지와 스택 추적(stack trace) 해석하기
• 가설 수립: 문제에 대한 합리적인 추측 세우기
• 디버깅 워크플로우: 단계별 조사 과정 익히기

코드 실행

먼저 전체 코드를 보지 않고 커널만 살펴봅시다:

fn add_10(
    output: UnsafePointer[Scalar[dtype], MutAnyOrigin],
    a: UnsafePointer[Scalar[dtype], MutAnyOrigin],
):
    i = thread_idx.x
    output[i] = a[i] + 10.0

버그를 직접 경험하려면 터미널에서 다음 명령을 실행하세요 (pixi 전용):

pixi run -e nvidia p09 --first-case

프로그램이 크래시하면 다음과 같은 출력이 나타납니다:

First Case: Try to identify what's wrong without looking at the code!

stack trace was not collected. Enable stack trace collection with environment variable `MOJO_ENABLE_STACK_TRACE_ON_ERROR`
Unhandled exception caught during execution: At open-source/max/mojo/stdlib/stdlib/gpu/host/device_context.mojo:2082:17: CUDA call failed: CUDA_ERROR_INVALID_IMAGE (device kernel image is invalid)
To get more accurate error information, set MODULAR_DEVICE_CONTEXT_SYNC_MODE=true.
/home/ubuntu/workspace/mojo-gpu-puzzles/.pixi/envs/nvidia/bin/mojo: error: execution exited with a non-zero result: 1

과제: 탐정 수사

도전: 코드를 보지 않은 상태에서, 이 크래시를 조사하기 위한 디버깅 전략은 무엇일까요?

다음 명령으로 시작해 보세요:

pixi run -e nvidia mojo debug --cuda-gdb --break-on-launch problems/p09/p09.mojo --first-case

pixi run -e nvidia mojo debug --cuda-gdb --break-on-launch problems/p09/p09.mojo --first-case

(cuda-gdb) run
CUDA thread hit breakpoint, p09_add_10_... (output=0x302000000, a=0x0)
    at /home/ubuntu/workspace/mojo-gpu-puzzles/problems/p09/p09.mojo:31
31          i = thread_idx.x

(cuda-gdb) next
32          output[i] = a[i] + 10.0
(cuda-gdb) print i
$1 = 0
(cuda-gdb) print output
$2 = (!pop.scalar<f32> * @register) 0x302000000
(cuda-gdb) print a
$3 = (!pop.scalar<f32> * @register) 0x0

(cuda-gdb) print a[i]
Cannot access memory at address 0x0

 input_buf = ctx.enqueue_create_buffer[dtype](0)  # 0개의 요소를 가진 `DeviceBuffer`를 생성합니다. 요소가 0개이므로 메모리가 할당되지 않아 NULL 포인터가 됩니다!

# 잘못된 방법: Null 포인터 생성
input_buf = ctx.enqueue_create_buffer[dtype](0)

# 올바른 방법: 안전한 처리를 위해 실제 GPU 메모리를 할당하고 초기화
input_buf = ctx.enqueue_create_buffer[dtype](SIZE)
input_buf.enqueue_fill(0)

다음 단계: 크래시에서 조용한 버그로

크래시 디버깅을 익혔습니다! 이제 할 수 있습니다:

• 오류 메시지를 단서로 GPU 크래시를 체계적으로 조사
• 포인터 주소 검사를 통해 null 포인터 버그 식별
• 메모리 관련 디버깅에 CUDA-GDB를 효과적으로 사용

다음 도전: 탐정 수사: 두 번째 사례

그런데 프로그램이 크래시하지 않는다면요? 완벽하게 실행되지만 잘못된 결과가 나온다면?

두 번째 사례는 전혀 다른 유형의 디버깅 도전입니다:

• 길잡이가 되어줄 크래시 메시지가 없습니다
• 조사할 뚜렷한 포인터 문제도 없습니다
• 문제를 가리키는 스택 추적도 없습니다
• 체계적인 조사가 필요한 잘못된 결과만 있습니다

새롭게 익히게 될 스킬:

• 로직 버그 탐지 - 크래시 없이 알고리즘 오류 찾기
• 패턴 분석 - 잘못된 출력에서 근본 원인까지 거슬러 올라가기
• 실행 흐름 디버깅 - 최적화 때문에 변수 검사가 안 될 때 대처하기

여기서 배운 체계적인 조사 방법 - 단서 읽기, 가설 세우기, 체계적으로 테스트하기 - 은 앞으로 마주할 더 미묘한 로직 오류를 디버깅하는 기초가 됩니다.