icon
16장 : 성능 최적화와 디버깅 기법

메모리 누수 탐지

C++과 같은 언어에서 동적 메모리 할당을 사용하는 경우, 또 다른 종류의 치명적인 오류가 발생할 수 있습니다.

바로 메모리 누수(Memory Leak) 입니다. 메모리 누수는 당장은 눈에 띄지 않지만, 프로그램의 성능 저하와 결국에는 시스템 전체의 안정성을 위협할 수 있는 심각한 문제입니다.

이번 장에서는 메모리 누수가 무엇인지 이해하고, 이를 탐지하고 해결하기 위한 다양한 기법과 도구들을 학습하겠습니다.

메모리 누수란 무엇인가?

메모리 누수는 프로그램이 동적으로 할당한 메모리(예: new 연산자를 통해 힙에 할당된 메모리)를 더 이상 사용하지 않음에도 불구하고, 해당 메모리를 운영체제에 반환(delete 연산자 호출)하지 않아 발생하는 현상입니다.

이렇게 반환되지 않은 메모리는 프로그램이 종료될 때까지 다른 용도로 재사용될 수 없으며, 마치 물이 새는 것처럼 계속 쌓여갑니다.

메모리 누수의 위험성

  • 성능 저하: 사용 가능한 물리 메모리가 줄어들어 운영체제가 가상 메모리(페이징 파일)를 더 자주 사용하게 되고, 이는 디스크 I/O를 유발하여 프로그램의 속도를 현저히 떨어뜨립니다.
  • 시스템 불안정: 결국에는 시스템의 사용 가능한 메모리를 모두 소진시켜 다른 프로그램이나 운영체제 자체의 오작동 또는 강제 종료를 유발할 수 있습니다.
  • 찾기 어려움: 당장 프로그램이 크래시되지 않아 발견하기 어렵고, 누수가 서서히 진행되기 때문에 원인을 파악하기가 매우 어렵습니다.

메모리 누수 발생 원인

  • new 또는 malloc으로 메모리를 할당했지만, 해당 메모리에 대한 delete 또는 free 호출을 누락한 경우.
  • 포인터 변수가 스코프를 벗어나거나 재할당되어 이전에 할당된 메모리 주소를 잃어버린 경우.
  • 예외 발생 등으로 delete 호출이 건너뛰어진 경우 (RAII를 사용하지 않았을 때).

스마트 포인터를 이용한 예방

가장 좋은 메모리 누수 탐지 및 해결책은 바로 예방입니다.

현대 C++에서는 스마트 포인터(Smart Pointer) 를 사용하여 동적 메모리 관리를 자동화하고 메모리 누수를 효과적으로 방지할 수 있습니다. (14장 3절 "스마트 포인터" 참조)

  • std::unique_ptr

    • 단일 소유권(exclusive ownership)을 가지는 스마트 포인터입니다.
    • unique_ptr 객체가 스코프를 벗어나 소멸될 때, 자신이 가리키는 메모리를 자동으로 delete합니다.
    • 메모리 누수와 댕글링 포인터(dangling pointer) 문제를 효과적으로 방지합니다.

  • std::shared_ptr

    • 공유 소유권(shared ownership)을 가지는 스마트 포인터입니다.
    • 참조 카운팅(reference counting) 방식을 사용하여, 해당 메모리를 가리키는 shared_ptr 객체가 모두 소멸될 때 메모리를 자동으로 delete합니다.
    • 순환 참조(circular reference) 시 메모리 누수가 발생할 수 있으므로 주의해야 합니다 (이 경우 std::weak_ptr 사용).
스마트 포인터 예제
#include <iostream>
#include <memory> // std::unique_ptr, std::shared_ptr을 위해

class MyClass {
public:
    int value;
    MyClass(int v) : value(v) {
        std::cout << "MyClass(" << value << ") created.\n";
    }
    ~MyClass() {
        std::cout << "MyClass(" << value << ") destroyed.\n";
    }
};

void leaky_function() {
    // raw pointer 사용: delete 호출을 잊으면 메모리 누수 발생
    MyClass* obj_ptr = new MyClass(1);
    // obj_ptr을 delete 하는 것을 잊었다면 누수
    // delete obj_ptr; // 이 라인이 없으면 누수
} // obj_ptr 스코프 벗어나도 힙 메모리는 해제되지 않음

void safe_unique_ptr_function() {
    // std::unique_ptr 사용: 스코프 벗어날 때 자동 해제
    std::unique_ptr<MyClass> obj_uptr = std::make_unique<MyClass>(2);
    // 아무것도 하지 않아도 자동으로 delete 호출
} // obj_uptr 소멸, MyClass(2) 자동 해제

void safe_shared_ptr_function() {
    // std::shared_ptr 사용: 참조 카운트가 0이 될 때 자동 해제
    std::shared_ptr<MyClass> obj_sptr1 = std::make_shared<MyClass>(3);
    std::shared_ptr<MyClass> obj_sptr2 = obj_sptr1; // 참조 카운트 증가

} // obj_sptr1, obj_sptr2 모두 소멸될 때 MyClass(3) 자동 해제

int main() {
    std::cout << "--- Calling leaky_function ---\n";
    leaky_function(); // 메모리 누수 발생 가능성

    std::cout << "\n--- Calling safe_unique_ptr_function ---\n";
    safe_unique_ptr_function(); // 자동 해제

    std::cout << "\n--- Calling safe_shared_ptr_function ---\n";
    safe_shared_ptr_function(); // 자동 해제

    std::cout << "\n--- Program finished ---\n";
    return 0;
}

새로운 C++ 코드를 작성할 때는 특별한 이유가 없다면 항상 스마트 포인터를 사용하여 동적 메모리를 관리하는 습관을 들여야 합니다.

메모리 누수 탐지 도구 (Memory Leak Detectors)

아무리 스마트 포인터를 사용해도 레거시 코드나 특정 라이브러리 사용 시, 또는 복잡한 시나리오에서는 여전히 메모리 누수가 발생할 수 있습니다.

이때 메모리 누수 탐지 도구들이 큰 도움이 됩니다.

  1. Valgrind (Memcheck)

    • Linux/macOS 환경에서 가장 강력하고 널리 사용되는 도구 중 하나입니다.
    • Memcheck라는 도구를 통해 메모리 누수, 유효하지 않은 메모리 접근, 해제된 메모리 사용 등을 탐지합니다.
    • 사용법: valgrind --leak-check=full ./your_program
    • 장점: 매우 정확하고 상세한 보고서를 제공하며, 메모리 관련 거의 모든 종류의 오류를 탐지합니다.
    • 단점: 프로그램 실행 속도가 매우 느려집니다 (5배~100배).
    Valgrind로 메모리 누수 탐지
    // leaky_program.cpp
#include <iostream>
#include <vector>

void create_leak() {
    int* p_int = new int(10); // 할당했지만 delete 하지 않음
    // p_int를 사용 후 버려짐.
    std::cout << "Leaked int at " << p_int << " with value " << *p_int << std::endl;

    std::vector<char>* p_vec = new std::vector<char>(1024); // 할당했지만 delete 하지 않음
    std::cout << "Leaked vector at " << p_vec << std::endl;
    // p_vec도 사용 후 버려짐
}

int main() {
    create_leak();
    std::cout << "Program exiting.\n";
    return 0;
}
    컴파일 및 Valgrind 실행
    g++ -g leaky_program.cpp -o leaky_program
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./leaky_program

    Valgrind는 누수된 메모리 블록의 크기, 할당된 위치(함수명, 라인 번호), 누수 종류(definitely lost, indirectly lost, possibly lost 등)를 상세하게 보고해 줍니다.

  2. Windows (Visual Studio Diagnostic Tools)

    • Visual Studio IDE에 통합된 "진단 도구" (Diagnostic Tools)는 메모리 사용량을 모니터링하고 스냅샷을 찍어 메모리 누수를 비교 분석할 수 있는 기능을 제공합니다.
    • 사용법: 디버깅 세션 중 "진단 도구" 창에서 "메모리 사용량" 탭을 활성화하고, "스냅샷 찍기" 버튼을 사용하여 프로그램의 특정 시점에서 메모리 스냅샷을 찍습니다. 두 스냅샷을 비교하여 어떤 객체가 할당된 후 해제되지 않았는지 추적할 수 있습니다.
    • CRT Debug Heap Functions: Microsoft Visual C++ 런타임 라이브러리는 디버그 모드에서 메모리 할당/해제 추적 기능을 제공합니다. (_CrtDumpMemoryLeaks, _CrtSetDbgFlag 등)

  3. AddressSanitizer (ASan)

    • GCC, Clang 컴파일러에 내장된 메모리 오류 탐지 도구입니다.
    • 컴파일 시점에 계측(instrumentation) 을 삽입하여 런타임에 메모리 오류를 탐지합니다.
    • 사용법: 컴파일 시 g++ -fsanitize=address your_program.cpp -o your_program 추가.
    • 장점: Valgrind보다 훨씬 빠릅니다 (보통 2배 오버헤드). 메모리 누수뿐만 아니라 Use-After-Free, Double-Free, Buffer Overflow/Underflow 등 다양한 메모리 오류를 탐지합니다.
    • 단점: 컴파일러 지원이 필요하고, 때로는 더 많은 메모리를 사용합니다.
    AddressSanitizer 사용 예시
    g++ -fsanitize=address -g leaky_program.cpp -o leaky_program
./leaky_program

    ASan은 누수 발견 시 바로 해당 정보를 출력하고 프로그램을 종료시킵니다.

  4. LeakSanitizer (LSan)

    • AddressSanitizer의 일부로, 메모리 누수 탐지에 특화되어 있습니다. ASan과 함께 활성화됩니다.

메모리 누수 탐지 전략

  1. 코드 리뷰

    • 가장 기본적인 방법입니다. new나 malloc이 사용된 곳을 찾아 delete나 free가 적절히 호출되는지 확인합니다.
    • 포인터의 소유권(ownership)이 명확한지 확인합니다.
    • RAII(Resource Acquisition Is Initialization) 원칙이 잘 지켜지고 있는지 확인합니다.

  2. 스마트 포인터 적극 활용

    • 새로운 코드 작성 시에는 std::unique_ptr과 std::shared_ptr을 기본적으로 사용합니다.

  3. 주기적인 프로파일링 및 테스트

    • 스트레스 테스트(Stress Test) 또는 장시간 실행 테스트를 통해 프로그램이 안정적으로 동작하는지 확인하고, 이 과정에서 메모리 누수 탐지 도구를 사용합니다.
    • 메모리 스냅샷을 주기적으로 찍어 메모리 사용량의 추이를 분석합니다.

  4. new / delete 오버로드 (Advanced)

    • 디버그 모드에서 전역 new 및 delete 연산자를 오버로드하여 할당/해제되는 모든 메모리 블록을 추적하는 커스텀 메모리 관리자를 구현할 수 있습니다. 이는 복잡하지만, 특정 환경에 최적화된 누수 탐지 시스템을 구축할 때 유용합니다.

누수된 메모리 블록 이해하기

탐지 도구가 보고하는 메모리 누수는 다양한 상태로 분류될 수 있습니다.

  • Definitely lost: 프로그램이 해당 메모리 블록에 대한 포인터를 전혀 가지고 있지 않아, 해당 메모리를 해제할 방법이 완전히 사라진 경우. (가장 심각한 누수)
  • Possibly lost: 프로그램이 해당 메모리 블록에 대한 포인터를 가지고 있을 가능성이 있지만, 그 포인터가 다른 유효한 메모리 블록 내부에 숨겨져 있을 수 있는 경우.
  • Still reachable: 프로그램이 해당 메모리 블록에 대한 포인터를 여전히 가지고 있지만, 프로그램 로직상 더 이상 사용되지 않을 것으로 판단되는 경우. (일반적으로는 누수가 아니지만, 의도치 않은 경우도 있음)

Definitely lost는 반드시 해결해야 할 문제입니다.

Possibly lost와 Still reachable은 코드의 맥락에 따라 중요도가 달라지지만, 대부분의 경우 조사하고 해결해야 합니다.

디버거 사용법

Previous Page