[MCU 디버깅] Wild Pointer 및 Dangling Pointer로 인한 시스템 다운 방지 대책

[Quick Summary (TL;DR) - For Global Developers]

• Symptom: Random system resets, infinite loops in HardFault_Handler, unexpected peripheral behaviors, or silent data corruption that alters operation based on Compiler Optimization levels.
• Cause: Dereferencing uninitialized pointer variables (Wild Pointer) or accessing memory addresses that have already been deallocated from the heap or stack frame (Dangling Pointer).
• Solution: Initialize all pointers to NULL, explicitly nullify pointers immediately after deallocation, validate pointers before dereferencing, and leverage hardware MPU (Memory Protection Unit) boundaries.

MCU Memory Corruption: Wild Pointer & Dangling Pointer Symptoms (포인터 오동작 발생 증상)

하드웨어 제어권이 완전히 열려 있는 베어메탈(Bare-metal) 환경이나 RTOS 기반의 MCU 커널 환경에서는 OS 수준의 메모리 격리(Memory Isolation)가 불가능합니다. 이로 인해 잘못된 포인터 참조는 단순 애플리케이션 종료가 아닌, 치명적인 하드웨어 예외 상황으로 직결됩니다.

런타임 중 마주치는 주요 하드웨어적/소프트웨어적 증상은 다음과 같습니다.

• HardFault_Handler 진입: 시스템이 하드웨어 예외를 처리하는 루프에 갇힙니다. 주로 메모리 정렬 불량으로 인한 Alignment Fault, 존재하지 않거나 쓰기가 제한된 영역에 접근할 때 발생하는 BusFault 혹은 UsageFault가 CPU 코어 레벨에서 트리거됩니다.
• 재현 불가능한 무작위 크래시 (Random Reset): 컴파일러 최적화 옵션(-O1, -O2, -O3) 레벨에 따라 증상이 완전히 바뀝니다. 디버그 빌드에서는 정상 동작하던 코드가 양산용 배포 빌드에서 무한 루프에 빠지거나 오작동합니다.
• 데이터 자동 오염 (Silent Data Overwrite): 포인터가 의도치 않은 RAM 주소를 가리킨 상태에서 데이터를 쓰면, 인접한 전역 변수나 주변장치 제어용 SFR (Special Function Register)을 임의로 덮어써 시스템 전반의 무결성을 깨뜨립니다.

MCU 레지스터 및 메모리 구조 관점의 포인터 오동작 원인 (Root Cause Analysis)

CPU 코어가 메모리 액세스 명령어(LDR, STR)를 처리하는 하드웨어적 메커니즘과 메모리 맵 배치 구조에서 원인을 찾을 수 있습니다.

1. 와일드 포인터(Wild Pointer)의 메커니즘

지역 변수로 선언된 포인터가 스택(Stack) 프레임에 할당될 때, 명시적인 초기화가 없으면 해당 스택 메모리 슬롯에 남아있던 이전 작업의 쓰레기 값(Garbage Value)을 주소로 가집니다. 이 상태에서 CPU가 STR 명령을 실행하면 엉뚱한 메모리 번지에 쓰기를 시도합니다. 이 주소가 물리적 SRAM이나 내부 플래시(Internal Flash)의 유효 범위를 벗어날 경우 메모리 관리 유닛이 이를 감지하여 즉시 BusFault를 발생시킵니다.

2. 댕글링 포인터(Dangling Pointer)의 메커니즘

malloc() 등으로 동적 할당한 힙(Heap) 메모리를 free()로 해제하면, 힙 메모리 관리자(Allocator)는 해당 블록을 '사용 가능' 상태로만 변경할 뿐입니다. 포인터 변수 자체는 여전히 해제된 물리 주소를 그대로 가리키고 있습니다.

만약 이 포인터를 지우지 않고 다시 역참조(Dereference)하여 데이터를 읽거나 쓰면 문제가 발생합니다. 이미 해당 메모리 블록이 ISR (Interrupt Service Routine)이나 다른 태스크에 의해 재할당되어 다른 용도로 사용 중일 수 있기 때문입니다. 이는 시스템 내부 제어 구조체를 파괴하는 결과를 낳습니다. 함수 내부의 지역 변수 주소를 반환하여 함수 종료 후 파괴된 스택 영역을 가리키게 만드는 경우도 동일한 원리입니다.

시스템 다운을 유발하는 잘못된 C 소스 코드 예시 (Bad Pointer Examples)

#include <stdlib.h>
#include <stdint.h>

typedef struct {
    uint32_t data[4];
} Packet_t;

/* Case 1: Wild Pointer (Uninitialized Local Pointer) */
void Process_RawData(void) {
    Packet_t *p_packet; // Bug: Contains garbage stack value. Not initialized to NULL.

    // System crashes into HardFault here depending on the garbage address value
    p_packet->data[0] = 0xDEADBEEF; 
}

/* Case 2: Dangling Pointer (Returning Stack Address) */
uint32_t* Get_SystemStatus(void) {
    uint32_t status_flag = 0x01;
    return &status_flag; // Bug: Returns address of a local variable that will be destroyed post-return
}

/* Case 3: Dangling Pointer (Missing Nullification after free) */
void Manage_HeapMemory(void) {
    Packet_t *p_dynamic = (Packet_t*)malloc(sizeof(Packet_t));
    if (p_dynamic == NULL) return;

    free(p_dynamic); // Memory freed, but p_dynamic still holds the old address

    // Bug: Dangling pointer dereference. Corrupts current heap state or metadata.
    p_dynamic->data[0] = 0xAAAA5555; 
}

MCU 시스템 안정성을 확보하는 방어적 C 소스 코드 (Defensive Pointer Patterns)

#include <stdlib.h>
#include <stdint.h>

typedef struct {
    uint32_t data[4];
} Packet_t;

/* Safe Free Macro to eliminate Dangling Pointers */
#define SAFE_FREE(ptr) do { free(ptr); (ptr) = NULL; } while(0)

/* Solution 1: Always Initialize and Validate Pointers */
void Safe_Process_RawData(void) {
    Packet_t *p_packet = NULL; // Initialized to NULL explicitly

    /* Code block allocating or assigning valid reference to p_packet */

    if (p_packet != NULL) {
        p_packet->data[0] = 0xDEADBEEF;
    }
}

/* Solution 2: Prevent Stack Address Leakage via Static Storage */
uint32_t* Safe_Get_SystemStatus(void) {
    static uint32_t status_flag = 0x01; // Persistent allocation in .data/.bss segment
    return &status_flag;
}

/* Solution 3: Enforce Safe Free Pattern */
void Safe_Manage_HeapMemory(void) {
    Packet_t *p_dynamic = (Packet_t*)malloc(sizeof(Packet_t));
    if (p_dynamic == NULL) return;

    // Frees memory and immediately updates pointer to NULL
    SAFE_FREE(p_dynamic); 

    // Guard condition prevents invalid memory operations
    if (p_dynamic != NULL) {
        p_dynamic->data[0] = 0xAAAA5555;
    }
}

핵심 수정 포인트 (Key Modifications)

• 포인터 선언과 동시에 NULL 초기화: 스택 내 잔여 쓰레기 값으로 인한 오동작을 원천 차단하기 위해 모든 포인터는 선언 시점에 NULL로 명시적 초기화를 수행합니다.
• SAFE_FREE 매크로 활용: 메모리 해제와 동시에 해당 포인터 변수에 자동으로 NULL을 주입하는 매크로 함수를 정의하여 사용함으로써 인간의 실수(Human Error)로 인한 댕글링 포인터 발생을 막습니다.
• 역참조 전 조건문 검증: 포인터를 통해 실제 가치에 접근하기 전 항상 if (ptr != NULL) 패턴을 적용하여, 유효성이 검증된 포인터만 메모리에 접근하도록 제한합니다.

하드폴트 예외 발생 시 포인터 추적 디버깅 가이드 (HardFault Debugging Tips)

• 하드웨어 에러 예외 스택 프레임 (Stack Frame) 역추적: HardFault가 트리거되는 순간 ARM Cortex-M 코어는 SP (Stack Pointer)가 가리키는 스택 영역에 R0-R3, R12, LR, PC, xPSR 레지스터 정보를 자동으로 백업(Stacking)합니다. 디버거(J-Link 또는 ST-Link) 인터페이스의 레지스터 뷰어 창에서 SP 주소를 찾아 해당 메모리 덤프의 PC (Program Counter) 값을 식별하면, 부적절한 포인터 접근을 명령한 소스 코드의 정확한 물리 행 위치를 찾을 수 있습니다.
• MAP 파일(Build Map File)을 활용한 주소 바운더리 체크: 디버깅 화면에서 오동작이 의심되는 포인터 변수의 16진수 주소 값을 복사한 뒤, 링커가 생성한 MAP 파일과 대조하십시오. 해당 주소가 하드웨어 데이터시트에 명시된 내부 SRAM, Flash 영역, Peripheral SFR 메모리 맵 경계선 바깥 영역을 가리키고 있다면 이는 포인터 초기화가 누락된 Wild Pointer 에러입니다.
• 데이터 워치포인트 (Data Watchpoint - DWT) 실시간 모니터링: 특정 전역 변수나 메모리 구조체 내부 값이 임의의 타이밍에 오염되고 있다면, 메모리 주소 자체에 IDE(Keil, IAR, STM32CubeIDE 등)의 Data Watchpoint 기능을 설정하십시오. 해당 번지에 쓰기(Write)가 시도되는 즉시 CPU 파이프라인이 멈추므로, 메모리를 오염시킨 주범(Dangling Pointer)이 속한 함수 컨텍스트를 런타임 상에서 실시간으로 색출할 수 있습니다.