Valgrind vs AddressSanitizer, 뭘 쓰나요?

Valgrind: 재컴파일 불필요, 더 많은 에러 탐지, 10~50배 느림. ASan: 2~5배 빠름, CI 적합. 로컬 심층 분석엔 Valgrind, CI·빠른 피드백엔 ASan 권장.

[2026] C++ Valgrind 완벽 가이드 | Memcheck·누수 탐지

Q: 이 내용을 실무에서 언제 쓰나요?

Valgrind Memcheck로 메모리 누수·버퍼 오버런·초기화 안 된 값을 찾고, suppression 파일로 외부 라이브러리 경고를 억제하며, CI에 통합해 프로덕션 전 검증하는 방법을 다룹니다.

Q: 더 깊이 공부하려면?

Valgrind 공식 문서(valgrind.org)와 Memcheck 매뉴얼을 참고하세요.

2026년 3월 11일 · 40분 읽기 · 수정 2026년 4월 7일 중급 실습

이 글의 핵심

C++ Valgrind Memcheck로 메모리 누수·버퍼 오버런·초기화 안 된 값 찾기. definitely lost·invalid read/write·uninitialized value 완전 예제, suppression 파일 작성, CI 통합, 프로덕션 패턴까지.

들어가며: “메모리가 계속 늘어나는데 원인을 못 찾겠어요”

Valgrind로 3일 걸리던 버그를 10분에 찾은 이야기

게임 서버가 24시간 돌아가다 보니, 메모리 사용량이 시간이 지날수록 계속 증가했습니다. 재시작하면 정상인데, 12시간 후면 OOM으로 죽는 패턴이 반복되었습니다. 코드를 눈으로 훑어봐도 new/delete 짝이 맞아 보였고, 어디서 누수가 나는지 감이 오지 않았습니다. Valgrind Memcheck를 돌려 보니, 10분 만에 “definitely lost: 2,048 bytes in 1 blocks”와 함께 정확한 파일:줄 번호가 나왔습니다. handleRequest 함수에서 early return 경로에 delete가 빠져 있었던 것입니다. 아래 코드는 mermaid를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

// 실행 예제
flowchart LR
  subgraph problem[문제]
    P1[메모리 증가]
    P2[원인 불명]
    P1 --> P2
  end
  subgraph solution[Valgrind로 해결]
    V[valgrind --leak-check=full]
    L[definitely lost 위치]
    F[코드 수정]
    V --> L --> F
  end
  problem --> solution

이 글을 읽으면:

Valgrind Memcheck로 메모리 누수·버퍼 오버런·초기화 안 된 값을 찾을 수 있습니다.
definitely lost, invalid read, uninitialized value 출력을 해석할 수 있습니다.
Suppression 파일로 외부 라이브러리 경고를 억제할 수 있습니다.
CI에 Valgrind를 통합하고 프로덕션 전 검증 패턴을 적용할 수 있습니다. 이전 글: C++ 메모리 누수에서 new/delete 위험 패턴을 다뤘습니다.

실무 적용 경험: 이 글은 대규모 C++ 프로젝트에서 실제로 겪은 문제와 해결 과정을 바탕으로 작성되었습니다. 책이나 문서에서 다루지 않는 실전 함정과 디버깅 팁을 포함합니다. 일상 비유로 이해하기: 메모리를 아파트 건물로 생각해보세요. 스택은 엘리베이터 같아서 빠르지만 공간이 제한적입니다. 힙은 창고처럼 넓지만 물건을 찾는 데 시간이 걸립니다. 포인터는 “3층 302호”처럼 주소를 가리키는 메모지라고 보면 됩니다.

문제 시나리오: Valgrind가 필요한 상황
Valgrind 개요 및 설치
Memcheck 완전 예제
메모리 누수 탐지 상세
Invalid Read/Write 탐지
초기화 안 된 값(Uninitialized Value)
Suppression 파일
자주 발생하는 에러와 해결법
베스트 프랙티스
Valgrind 출력 해석 가이드
프로덕션 패턴 및 CI 통합
Valgrind vs AddressSanitizer 비교
Suppression 파일 예제 확장
Valgrind Memcheck 동작 흐름
실제 디버깅 워크플로우
FAQ
체크리스트

1. 문제 시나리오: Valgrind가 필요한 상황

시나리오 1: “서버가 2-3시간마다 죽어요”

"메모리 사용량이 500MB에서 7GB까지 계속 증가하다가 OOM으로 죽어요."
"코드를 보면 new/delete가 맞아 보이는데, 어디서 누수인지 모르겠어요."

원인: early return, 예외, 여러 분기 경로에서 delete가 누락된 경우. Valgrind Memcheck의 --leak-check=full로 정확한 할당 위치와 누수 경로를 찾을 수 있습니다.

시나리오 2: “특정 입력에서만 Segmentation fault”

"길이 1000인 배열은 괜찮은데, 1001이면 터져요."
"버퍼 오버런인 것 같은데, 어디서 넘어썼는지 모르겠어요."

원인: 배열 인덱스 범위 초과, strcpy/memcpy 길이 오류. Valgrind는 Invalid write of size N으로 정확한 주소와 스택을 보고합니다.

시나리오 3: “결과가 가끔 이상해요”

"같은 입력인데 실행마다 결과가 달라요."
"초기화 안 한 변수를 쓴 것 같은데, 찾기 어려워요."

원인: 스택/힙 변수를 초기화하지 않고 사용. Valgrind의 Conditional jump or move depends on uninitialised value로 정확한 사용 위치를 찾을 수 있습니다.

시나리오 4: “delete 후 포인터를 또 썼어요”

"해제한 메모리를 참조했다가 크래시해요."
"use-after-free인데, 어디서 발생하는지 추적이 안 돼요."

원인: delete 후 포인터를 null로 만들지 않았거나, 다른 경로에서 해제된 메모리 접근. Valgrind는 Invalid read of size N으로 해제 위치와 접근 위치를 모두 보고합니다.

시나리오 5: “외부 라이브러리에서 경고가 쏟아져요”

"우리 코드는 괜찮은데, OpenSSL/glibc에서 'still reachable'이 수천 개 나와요."
"진짜 우리 버그와 구분이 안 돼요."

원인: 라이브러리가 종료 시 명시적으로 해제하지 않는 메모리를 남김. Suppression 파일로 해당 경고를 억제할 수 있습니다.

시나리오 6: “네트워크 서버가 클라이언트 수에 비례해 메모리가 늘어나요”

"동시 접속 100명일 때 200MB, 1000명일 때 2GB로 비례해서 증가해요."
"연결이 끊겨도 메모리가 해제되지 않는 것 같아요."

원인: accept 후 생성한 세션 객체, 버퍼, 이벤트 핸들러가 close/disconnect 시 해제되지 않음. Valgrind의 reachable blocks로 연결당 할당된 블록을 추적할 수 있습니다.

시나리오 7: “std::vector resize 후 범위 밖 접근”

"벡터에 push_back하다가 가끔 크래시해요."
"reserve와 size를 혼동한 것 같은데, 정확한 위치를 모르겠어요."

원인: reserve는 용량만 확보하고 size는 그대로. operator[]로 size() 밖 인덱스 접근 시 Valgrind가 Invalid write로 보고합니다.

시나리오 8: “멀티스레드에서 가끔만 터져요”

"단일 스레드는 괜찮은데, 4스레드로 돌리면 10번 중 1번 정도 크래시해요."
"데이터 레이스인지, 메모리 오류인지 구분이 안 돼요."

원인: 레이스 컨디션으로 한 스레드가 delete한 메모리를 다른 스레드가 접근. Valgrind Memcheck는 Invalid read로 use-after-free를 보고하고, Helgrind는 데이터 경합을 별도 탐지합니다.

시나리오 9: “예외 발생 시 메모리가 해제되지 않아요”

"파싱 중 예외가 나면 그 시점에 할당한 버퍼가 해제되지 않는 것 같아요."
"try-catch는 있는데, 예외 경로에서 delete가 호출되지 않아요."

원인: try 블록 내 new 후 예외 발생 시 catch까지 delete가 실행되지 않음. Valgrind는 definitely lost로 예외 발생 직전 할당 위치를 보고합니다. 해결: RAII·스마트 포인터 사용.

시나리오 10: “delete[]와 delete를 혼동했어요”

"배열을 delete로 해제했는데, 가끔 힙 손상으로 크래시해요."
"new[]로 할당했는데 delete만 썼어요."

원인: `new[]`로 할당한 메모리를 `delete`로 해제하면 undefined behavior. Valgrind는 Invalid free() 또는 Mismatched free()로 보고합니다. 해결: `new[]` ↔ `delete[]`, `new` ↔ `delete` 짝 맞추기.

2. Valgrind 개요 및 설치

Valgrind란?

Valgrind는 동적 바이너리 계측 도구입니다. 프로그램을 가상 CPU에서 실행해 모든 메모리 접근·할당·해제를 추적합니다. 재컴파일 없이 기존 바이너리에 적용할 수 있지만, 10~50배 느려지므로 짧은 실행·단위 테스트에 사용합니다.

Valgrind 도구 비교

도구	용도	명령 예시
Memcheck	메모리 누수, 잘못된 접근, 초기화 안 된 값	`valgrind --tool=memcheck ./app`
Callgrind	CPU 프로파일링	`valgrind --tool=callgrind ./app`
Cachegrind	캐시 미스 시뮬레이션	`valgrind --tool=cachegrind ./app`
Helgrind	데이터 경합	`valgrind --tool=helgrind ./app`
이 글에서는 Memcheck를 중심으로 다룹니다. `--tool`을 생략하면 기본값이 Memcheck입니다.

설치

아래 코드는 bash를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# Ubuntu/Debian
sudo apt install valgrind
# Fedora/RHEL
sudo dnf install valgrind
# macOS (Homebrew)
brew install valgrind
# 버전 확인
valgrind --version

컴파일 시 필수: 디버그 심볼

Valgrind가 파일:줄 번호를 정확히 보고하려면 -g 옵션이 필수입니다. 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# ✅ 올바른 컴파일
g++ -g -O0 -std=c++17 -o myapp myapp.cpp
# ❌ -g 없으면 함수 이름만 나오고 줄 번호 없음
g++ -O2 -std=c++17 -o myapp myapp.cpp

-O0 권장: 최적화가 심하면 인라인·재정렬로 줄 번호가 어긋날 수 있습니다.

3. Memcheck 완전 예제

기본 실행

다음은 bash를 활용한 상세한 구현 코드입니다. 에러 처리를 통해 안정성을 확보합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 가장 단순한 실행 (기본 도구 = Memcheck)
valgrind ./myapp
# 누수 상세 분석 (권장)
valgrind --leak-check=full --show-leak-kinds=all ./myapp
# 로그 파일로 저장
valgrind --leak-check=full --log-file=valgrind.log ./myapp
# 에러 발생 시 exit code 1로 종료 (CI용)
valgrind --leak-check=full --error-exitcode=1 ./myapp
# 자식 프로세스까지 추적 (fork/exec 사용 시)
valgrind --trace-children=yes ./myapp
# 미초기화 값의 출처 추적 (uninitialised value 디버깅에 필수)
valgrind --track-origins=yes ./myapp
# 조용한 모드 (에러만 출력, CI에서 로그 정리)
valgrind --leak-check=full --error-exitcode=1 --quiet ./myapp

Memcheck 핵심 옵션 요약

옵션	용도
`--leak-check=full`	누수 발생 위치의 전체 스택 트레이스
`--show-leak-kinds=all`	definitely/indirectly/possibly/still reachable 모두 표시
`--track-origins=yes`	미초기화 값이 어디서 생성되었는지 추적
`--trace-children=yes`	fork로 생성된 자식 프로세스도 검사
`--error-exitcode=1`	에러 시 비정상 종료 (CI 연동용)
`--gen-suppressions=all`	출력을 suppression 형식으로 생성

예제 1: 메모리 누수 (definitely lost)

코드 (leak_example.cpp): 다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 클래스를 정의하여 데이터와 기능을 캡슐화하며, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

#include <iostream>
#include <string>
struct Data {
    std::string content;
    explicit Data(const std::string& s) : content(s) {}
};
void process(const std::string& input) {
    Data* data = new Data(input);
    if (input.empty()) {
        return;  // ❌ delete 없이 리턴 → 누수
    }
    std::cout << data->content << "\n";
    delete data;
}
int main() {
    process("hello");
    process("");  // 여기서 누수
    return 0;
}

컴파일 및 실행:

g++ -g -O0 -std=c++17 -o leak_example leak_example.cpp
valgrind --leak-check=full --show-leak-kinds=all ./leak_example

Valgrind 출력: 아래 코드는 text를 사용한 구현 예제입니다. 에러 처리를 통해 안정성을 확보합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2E0EF: operator new(unsigned long) (vg_replace_malloc.c:334)
==12345==    by 0x400A3C: process(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (leak_example.cpp:12)
==12345==    by 0x400B12: main (leak_example.cpp:22)
==12345==
==12345== LEAK SUMMARY:
==12345==    definitely lost: 40 bytes in 1 blocks
==12345==    indirectly lost: 0 bytes in 0 blocks
==12345==      possibly lost: 0 bytes in 0 blocks
==12345==    still reachable: 0 bytes in 0 blocks
==12345==         suppressed: 0 bytes in 0 blocks
==12345== ERROR SUMMARY: 1 errors from 1 contexts

해석:

definitely lost: 확실한 누수. 반드시 수정해야 함.
by 0x400A3C: process(...) (leak_example.cpp:12): 12번째 줄 new Data에서 할당.
by 0x400B12: main (leak_example.cpp:22): 22번째 줄 process("") 호출 시 누수 발생. 수정: 아래 코드는 cpp를 사용한 구현 예제입니다. 조건문으로 분기 처리를 수행합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

void process(const std::string& input) {
    auto data = std::make_unique<Data>(input);
    if (input.empty()) {
        return;  // ✅ unique_ptr 소멸 시 자동 해제
    }
    std::cout << data->content << "\n";
}

4. 메모리 누수 탐지 상세

누수 종류 (Leak Kinds)

종류	의미	대응
definitely lost	포인터가 완전히 손실됨. 반드시 수정	`delete` 추가 또는 스마트 포인터
indirectly lost	definitely lost로 인해 해제되지 않은 자식 블록	부모 수정 시 함께 해결
possibly lost	내부 포인터만 남아 있을 수 있음 (예: 중간 포인터)	검토 필요
still reachable	종료 시점에 포인터가 남아 있음 (전역, atexit 등)	의도적이면 무시 가능

예제 2: indirectly lost

코드 (leak_indirect.cpp): 다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 클래스를 정의하여 데이터와 기능을 캡슐화하며. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

#include <iostream>
struct Node {
    int value;
    Node* next;
    explicit Node(int v) : value(v), next(nullptr) {}
};
int main() {
    Node* head = new Node(1);
    head->next = new Node(2);
    head->next->next = new Node(3);
    delete head;  // ❌ next, next->next 해제 안 됨
    return 0;
}

Valgrind 출력: 다음은 간단한 text 코드 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== 24 bytes in 1 blocks are indirectly lost in loss record 2 of 3
==12345== 24 bytes in 1 blocks are indirectly lost in loss record 3 of 3
==12345== 24 bytes in 1 blocks are definitely lost in loss record 1 of 3
==12345==    by 0x400A12: main (leak_indirect.cpp:11)

해석: head만 delete하고 next 체인은 해제하지 않음. definitely lost 1개 + indirectly lost 2개. 수정: 아래 코드는 cpp를 사용한 구현 예제입니다. 반복문으로 데이터를 처리합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

int main() {
    Node* head = new Node(1);
    head->next = new Node(2);
    head->next->next = new Node(3);
    while (head) {
        Node* tmp = head;
        head = head->next;
        delete tmp;
    }
    return 0;
}

예제 3: still reachable (라이브러리)

==12345== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 2
==12345==    by 0x4E3F2A1: __gthread_once (gthr-default.h:699)
==12345==    by 0x4E3F3B2: std::locale::locale() (locale.cc:78)

해석: C++ 표준 라이브러리 std::locale이 종료 시 명시적으로 해제하지 않는 메모리. 의도된 동작이므로 무시해도 됩니다. Suppression 파일로 억제 가능. possibly lost 참고: 블록 시작 주소를 잃고 내부 포인터만 남았을 때 발생합니다. 라이브러리 내부 realloc 패턴에서도 나올 수 있어, 우리 코드면 수정, 외부 라이브러리면 suppression을 고려합니다.

누수 탐지 옵션 정리

아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# 모든 누수 종류 표시
valgrind --leak-check=full --show-leak-kinds=all ./myapp
# definitely lost만 에러로 (still reachable 무시)
valgrind --leak-check=full --show-leak-kinds=definite ./myapp
# 누수 요약만 (상세 스택 생략)
valgrind --leak-check=summary ./myapp

5. Invalid Read/Write 탐지

예제 4: 버퍼 오버런 (Invalid write)

코드 (overflow_example.cpp): 아래 코드는 cpp를 사용한 구현 예제입니다. 필요한 모듈을 import하고. 코드를 직접 실행해보면서 동작을 확인해보세요.

#include <iostream>
#include <cstring>
int main() {
    char buf[8];
    strcpy(buf, "123456789");  // ❌ 9바이트 + null → 오버플로우
    std::cout << buf << "\n";
    return 0;
}

Valgrind 실행:

g++ -g -O0 -std=c++17 -o overflow_example overflow_example.cpp
valgrind ./overflow_example

Valgrind 출력: 아래 코드는 text를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Invalid write of size 2
==12345==    at 0x4C32E34: strcpy (vg_replace_strmem.c:513)
==12345==    by 0x4007A2: main (overflow_example.cpp:7)
==12345==  Address 0x1ffefff6e8 is 0 bytes after a block of size 8 alloc'd
==12345==    at 0x4C2E0EF: operator new(unsigned long)
==12345==    by 0x40078A: main (overflow_example.cpp:6)

해석:

Invalid write of size 2: 2바이트를 허용 범위 밖에 씀 (null 포함).
Address ....is 0 bytes after a block of size 8: 8바이트 블록 바로 다음 주소에 접근.

예제 5: 배열 인덱스 초과·vector reserve/size 혼동

코드 (array_oob.cpp):

int* arr = new int[10];
for (int i = 0; i <= 10; ++i) arr[i] = i;  // ❌ i=10 범위 초과
delete[] arr;

vector: v.reserve(100); v[0] = 42 — reserve는 capacity만 늘리고 size()는 0. operator[]로 size() 밖 접근 시 Invalid write. Valgrind 출력: 아래 코드는 text를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Invalid write of size 4
==12345==    at 0x4007B2: main (array_oob.cpp:7)
==12345==  Address 0x5b7c048 is 0 bytes after a block of size 40 alloc'd
==12345==    at 0x4C2E0EF: operator new(unsigned long)
==12345==    by 0x40078A: main (array_oob.cpp:6)

예제 6: Use-after-free (Invalid read)

코드 (use_after_free.cpp): 아래 코드는 cpp를 사용한 구현 예제입니다. 필요한 모듈을 import하고. 코드를 직접 실행해보면서 동작을 확인해보세요.

#include <iostream>
int main() {
    int* p = new int(42);
    delete p;
    std::cout << *p << "\n";  // ❌ 해제된 메모리 읽기
    return 0;
}

Valgrind 출력: 아래 코드는 text를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Invalid read of size 4
==12345==    at 0x4007A2: main (use_after_free.cpp:7)
==12345==  Address 0x5b7c040 is 0 bytes inside a block of size 4 free'd
==12345==    at 0x4C2F24B: operator delete(void*) (vg_replace_malloc.c:576)
==12345==    by 0x40079A: main (use_after_free.cpp:6)
==12345==  Block was alloc'd at
==12345==    at 0x4C2E0EF: operator new(unsigned long)
==12345==    by 0x40078A: main (use_after_free.cpp:5)

해석: delete p 후 *p 읽기. 해제 위치(6번 줄)와 접근 위치(7번 줄) 모두 표시.

예제 6-2: 이중 해제 (Double free)

코드 (double_free.cpp): 아래 코드는 cpp를 사용한 구현 예제입니다. 필요한 모듈을 import하고. 코드를 직접 실행해보면서 동작을 확인해보세요.

#include <iostream>
int main() {
    int* p = new int(42);
    delete p;
    delete p;  // ❌ 같은 포인터 두 번 해제
    return 0;
}

Valgrind 출력: 아래 코드는 text를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Invalid free() / delete / delete[] / realloc()
==12345==    at 0x4C2F24B: operator delete(void*) (vg_replace_malloc.c:576)
==12345==    by 0x4007B2: main (double_free.cpp:7)
==12345==  Address 0x5b7c040 is 0 bytes inside a block of size 4 free'd
==12345==    at 0x4C2F24B: operator delete(void*)
==12345==    by 0x4007A2: main (double_free.cpp:6)

해석: 두 번째 delete p에서 “이미 해제된 블록을 다시 해제”했다고 보고. 해결: delete 후 p = nullptr로 두면 실수로 이중 해제 시에도 안전하지만, 근본적으로는 스마트 포인터 사용 권장.

예제 6-3: Mismatched free (delete vs delete[])

코드 (mismatched_free.cpp): 아래 코드는 cpp를 사용한 구현 예제입니다. 필요한 모듈을 import하고. 코드를 직접 실행해보면서 동작을 확인해보세요.

#include <iostream>
int main() {
    int* arr = new int[10];
    delete arr;  // ❌ new[]인데 delete 사용 → Mismatched free
    return 0;
}

Valgrind 출력: 아래 코드는 text를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Mismatched free() / delete / delete[]
==12345==    at 0x4C2F24B: operator delete(void*)
==12345==    by 0x4007A2: main (mismatched_free.cpp:6)
==12345==  Address 0x5b7c040 is 0 bytes inside a block of size 40 alloc'd
==12345==    at 0x4C2F0EF: operator new
==12345==    by 0x40078A: main (mismatched_free.cpp:5)

해석: `new[]`로 할당했으면 반드시 `delete[]`로 해제해야 합니다.

6. 초기화 안 된 값(Uninitialized Value)

예제 7: 스택 변수 미초기화

코드 (uninit_example.cpp): 아래 코드는 cpp를 사용한 구현 예제입니다. 필요한 모듈을 import하고, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

#include <iostream>
int main() {
    int x;  // ❌ 초기화 안 함
    if (x > 0) {
        std::cout << "positive\n";
    } else {
        std::cout << "non-positive\n";
    }
    return 0;
}

Valgrind 출력 (기본): 다음은 간단한 text 코드 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Conditional jump or move depends on uninitialised value(s)
==12345==    at 0x4007A2: main (uninit_example.cpp:6)
==12345==  Uninitialised value was created by a stack allocation
==12345==    at 0x40078A: main (uninit_example.cpp:5)

--track-origins=yes로 실행하면 “Uninitialised value was created by a stack allocation at (uninit_example.cpp:5)“처럼 값이 어디서 생성되었는지 명확히 출력됩니다.

예제 8: 힙 버퍼 일부 미초기화

코드 (uninit_buffer.cpp): 다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 반복문으로 데이터를 처리합니다, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

#include <iostream>
#include <cstring>
int main() {
    char* buf = new char[100];
    std::strcpy(buf, "hello");  // 6바이트만 초기화, 나머지 94바이트 미초기화
    size_t len = std::strlen(buf);
    for (size_t i = 0; i < len + 10; ++i) {  // ❌ len+10까지 접근
        if (buf[i] == 'x') {  // 미초기화 영역 읽기
            std::cout << "found x\n";
        }
    }
    delete[] buf;
    return 0;
}

Valgrind 출력: 아래 코드는 text를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Conditional jump or move depends on uninitialised value(s)
==12345==    at 0x4C32E80: strlen (vg_replace_strmem.c:...)
==12345==    by 0x4007C2: main (uninit_buffer.cpp:9)
==12345==  Uninitialised value was created by a heap allocation
==12345==    at 0x4C2E0EF: operator new(unsigned long)
==12345==    by 0x4007A2: main (uninit_buffer.cpp:7)

예제 9: 구조체 멤버 미초기화

코드 (uninit_struct.cpp): 아래 코드는 cpp를 사용한 구현 예제입니다. 필요한 모듈을 import하고, 클래스를 정의하여 데이터와 기능을 캡슐화하며, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

#include <iostream>
struct Config {
    int timeout;
    bool use_ssl;
};
int main() {
    Config cfg;  // ❌ 멤버 미초기화
    if (cfg.timeout > 0) {
        std::cout << "timeout=" << cfg.timeout << "\n";
    }
    return 0;
}

Valgrind 출력 (--track-origins=yes 권장): 다음은 간단한 text 코드 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

==12345== Conditional jump or move depends on uninitialised value(s)
==12345==    at 0x4007B2: main (uninit_struct.cpp:10)
==12345==  Uninitialised value was created by a stack allocation
==12345==    at 0x40078A: main (uninit_struct.cpp:9)

수정: Config cfg{} 또는 멤버 기본값 설정 (int timeout = 0;).

수정: 항상 초기화

다음은 cpp를 활용한 상세한 구현 코드입니다. 클래스를 정의하여 데이터와 기능을 캡슐화하며. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

// ✅ 스택
int x = 0;
// ✅ 힙 버퍼
char* buf = new char[100]();  // zero-initialize
// 또는
std::memset(buf, 0, 100);
// ✅ 구조체
struct Config {
    int timeout = 0;
    bool use_ssl = false;
    char* hostname = nullptr;
};
// 또는
Config cfg{};  // 모든 멤버 0으로 초기화

7. Suppression 파일

왜 Suppression이 필요한가?

외부 라이브러리(OpenSSL, glibc, C++ 표준 라이브러리)가 의도적으로 종료 시 해제하지 않는 메모리가 있어서, Valgrind가 still reachable로 보고합니다. 우리 코드의 진짜 버그와 구분하기 위해 해당 경고를 억제합니다.

Suppression 파일 작성

파일 (valgrind.supp): 아래 코드는 text를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

{
   libc_locale
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:__gthread_once
   fun:_ZNSt6localeC1Ev
}
{
   openssl_init
   Memcheck:Leak
   match-leak-kinds: reachable
   obj:*/libssl.so*
   obj:*/libcrypto.so*
}

사용:

valgrind --leak-check=full --suppressions=valgrind.supp ./myapp

Suppression 생성 (자동)

Valgrind가 출력한 에러를 그대로 suppression으로 저장할 수 있습니다. 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# 1. 에러 출력을 파일로
valgrind --leak-check=full --gen-suppressions=all ./myapp 2>&1 | tee valgrind_raw.log
# 2. 출력에서 { ....} 블록을 복사해 .supp 파일에 붙여넣기
# 3. 이름을 의미 있게 수정 (예: libc_locale → our_libc_suppression)

출력 예시: 아래 코드는 text를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:__gthread_once
   fun:_ZNSt6localeC1Ev
   ...
}

Suppression 문법 요약

필드	의미
`Memcheck:Leak`	누수 억제
`Memcheck:Addr1`	잘못된 주소 접근 억제
`Memcheck:Value4`	초기화 안 된 값 억제
`match-leak-kinds: reachable`	still reachable만
`fun:함수이름`	특정 함수에서 발생한 것만
`obj:/libssl.so`	특정 라이브러리

Suppression 작성 시 주의사항

와일드카드(`fun:SSL`, `obj:/libssl`) 사용 가능. 여러 조건은 AND. 우리 코드의 `definitely lost`는 suppression 금지, 반드시 수정. 검증: `valgrind --suppressions=valgrind.supp ./myapp 2>&1 | grep suppressed`

8. 자주 발생하는 에러와 해결법

에러 1: “Valgrind: failed to start tool ‘memcheck’”

원인: Valgrind 설치 불완전 또는 아키텍처 불일치. 해결: 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# 재설치
sudo apt install --reinstall valgrind
# 32비트 바이너리에 64비트 Valgrind 사용 시
# 해당 아키텍처용 Valgrind 설치 확인

에러 2: “valgrind: Cannot find memory map”

원인: macOS에서 일부 바이너리와 호환 문제. 해결: 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# macOS: 최신 Valgrind 사용
brew upgrade valgrind
# 또는 Docker/Linux VM에서 실행
docker run -v $(pwd):/work -w /work ubuntu:22.04 valgrind ./myapp

에러 3: “definitely lost”가 나오는데 코드상 delete가 있어요

원인: 예외 발생 시 delete가 실행되지 않는 경로. 해결: try/catch 내 모든 경로에서 delete 호출 확인. 또는 unique_ptr/shared_ptr로 교체.

에러 4: “Conditional jump on uninitialised value” - false positive

원인: 인라인 어셈블리, JIT 생성 코드, 특정 라이브러리 내부. 해결: Suppression 파일에 추가. 또는 해당 코드 경로를 Valgrind 없이 별도 테스트.

에러 5: Valgrind가 너무 느려서 CI에서 타임아웃

원인: Valgrind는 10~50배 느림. 해결:

입력 크기 축소 (테스트용 작은 데이터)
--error-exitcode=1로 첫 에러에서 즉시 종료
ASan(-fsanitize=address,leak)을 CI 주력으로, Valgrind는 주기적(예: 매일) 실행

에러 6: “still reachable”이 수천 개

원인: C++ 표준 라이브러리, OpenSSL 등이 종료 시 해제하지 않는 메모리. 해결: Suppression 파일로 억제. 우리 코드 경로(src/, main.cpp 등)만 필터링해 확인.

에러 7: “Valgrind: invalid combination of options”

--leak-check=summary일 때는 --show-leak-kinds가 무시됩니다. --leak-check=full과 함께 사용하세요.

에러 8: “Fatal error: call to builtin_strcpy_chk”

_FORTIFY_SOURCE와 Valgrind가 충돌할 수 있습니다. g++ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0으로 컴파일하세요.

에러 9: “Valgrind: debug info not found”

-g 없이 컴파일했거나 스트립된 바이너리입니다. g++ -g -O0으로 빌드하고 strip하지 마세요.

에러 10: “Mismatched free() / delete / delete[]”

원인: new[]↔delete, new↔delete[] 혼동. 해결: new↔delete, new[]↔delete[] 짝 맞추기.

에러 11: “still reachable만 있는데 exit code 1”

해결: `--show-leak-kinds=definite,indirect`로 definitely/indirectly만 에러로 처리하거나, `still reachable`을 suppression으로 억제.

9. 베스트 프랙티스

-g로 컴파일: g++ -g -O0 -std=c++17 -o myapp myapp.cpp
CI error-exitcode: valgrind --leak-check=full --error-exitcode=1 --quiet ./myapp
로그 저장: --log-file=valgrind_$(date +%Y%m%d_%H%M).log
definitely lost 우선: still reachable은 suppression, 나머지 수정
테스트 축소: --gtest_filter="*Memory*" 등
ASan 병행: 개발은 ASan, 릴리스 전 Valgrind
track-origins=yes: 미초기화 값 출처 추적 필수
최소 권한 실행: 테스트용 계정
예외 경로 검증: 예외를 던지는 테스트로 Valgrind 실행. 경로 불일치 시 --fullpath-after

Valgrind 출력 해석 가이드

출력 요소	의미
`==PID==`	Valgrind가 추적 중인 프로세스 ID
HEAP SUMMARY	종료 시점 힙 상태 (할당/해제/손실 바이트)
LEAK SUMMARY	definitely/indirectly/possibly/still reachable/suppressed
ERROR SUMMARY	발견된 에러 개수 (`N errors from M contexts`)
스택 트레이스	맨 위 = 에러 발생 위치, 맨 아래 = 호출 시작. `(파일:줄)`이 수정할 위치
스택 읽는 법: `by 0x....: 함수명 (파일:줄)` → 해당 줄에서 할당/접근/해제 발생.

10. 프로덕션 패턴 및 CI 통합

패턴 1: CMake Valgrind 타겟

아래 코드는 cmake를 사용한 구현 예제입니다. 에러 처리를 통해 안정성을 확보합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

add_custom_target(valgrind
  COMMAND valgrind --leak-check=full --error-exitcode=1
          --suppressions=${CMAKE_SOURCE_DIR}/valgrind.supp
          $<TARGET_FILE:myapp> --test
  WORKING_DIRECTORY ${CMAKE_BINARY_DIR})

cmake --build . --target valgrind로 실행.

패턴 2: GitHub Actions

아래 코드는 yaml를 사용한 구현 예제입니다. 에러 처리를 통해 안정성을 확보합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# .github/workflows/valgrind.yml
on: [push, pull_request]
jobs:
  valgrind:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: sudo apt-get install -y valgrind
      - run: mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Debug ...&& make
      - run: cd build && valgrind --leak-check=full --error-exitcode=1 --suppressions=../valgrind.supp ./myapp --test

패턴 3: 스크립트 래퍼

다음은 간단한 bash 코드 예제입니다. 에러 처리를 통해 안정성을 확보합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

#!/bin/bash
# scripts/run_valgrind.sh
VALGRIND_OPTS="--leak-check=full --show-leak-kinds=all --error-exitcode=1 --suppressions=$(dirname $0)/../valgrind.supp --log-file=valgrind_$$.log"
valgrind $VALGRIND_OPTS "$@"

패턴 4: 프로덕션에서는 Valgrind 사용 금지

Valgrind는 10~50배 느림이므로 프로덕션 바이너리에 붙이지 않습니다. 테스트·CI·로컬 디버깅에만 사용합니다.

패턴 5: Docker (macOS ARM 대안)

아래 코드는 dockerfile를 사용한 구현 예제입니다. 에러 처리를 통해 안정성을 확보합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y valgrind g++ make
WORKDIR /app
COPY . .
RUN make CXXFLAGS="-g -O0"
CMD ["valgrind", "--leak-check=full", "--error-exitcode=1", "./myapp"]

docker build -f Dockerfile.valgrind -t myapp-valgrind . && docker run --rm myapp-valgrind

패턴 6: Makefile Valgrind 타겟

다음은 간단한 makefile 코드 예제입니다. 에러 처리를 통해 안정성을 확보합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

VALGRIND_OPTS = --leak-check=full --show-leak-kinds=all --error-exitcode=1 --suppressions=valgrind.supp
.PHONY: valgrind
valgrind: myapp
	valgrind $(VALGRIND_OPTS) ./myapp

패턴 7: 스케줄 기반 CI (느린 테스트)

Valgrind가 느리면 CI에서 schedule(예: 매일 02:00)으로 실행하고, timeout-minutes: 60으로 타임아웃을 설정합니다. GitHub Actions 스케줄 예시: 아래 코드는 yaml를 사용한 구현 예제입니다. 에러 처리를 통해 안정성을 확보합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# .github/workflows/valgrind-nightly.yml
on:
  schedule:
    - cron: '0 2 * * *'  # 매일 02:00 UTC
jobs:
  valgrind:
    runs-on: ubuntu-latest
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v4
      - run: mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Debug ...&& make
      - run: cd build && valgrind --leak-check=full --error-exitcode=1 --suppressions=../valgrind.supp ./myapp --run-all-tests

패턴 8: 로컬용 옵션

빠른 확인: `valgrind --leak-check=summary --error-exitcode=1 ./myapp`
심층 분석: `valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./myapp`

Valgrind vs AddressSanitizer 비교

언제 무엇을 쓸까?

아래 코드는 mermaid를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

flowchart TD
  A[메모리 버그 의심] --> B{재컴파일 가능?}
  B -->|Yes| C{CI/빠른 피드백 필요?}
  B -->|No| D[Valgrind]
  C -->|Yes| E[AddressSanitizer]
  C -->|No| F{심층 분석 필요?}
  F -->|Yes| D
  F -->|No| E

상세 비교표

항목	Valgrind Memcheck	AddressSanitizer
재컴파일	불필요	`-fsanitize=address,leak` 필요
오버헤드	10~50배 느림	2~5배 느림
CPU 사용	가상 CPU 시뮬레이션	계측 코드 삽입
누수 탐지	definitely/indirectly/possibly/still reachable 구분	LeakSanitizer(LSan)
초기화 안 된 값	✅	❌ (MemorySanitizer 별도)
버퍼 오버런	✅	✅
Use-after-free	✅	✅
CI 적합성	느림, 타임아웃 주의	적합
플랫폼	Linux, macOS(제한적)	Linux, macOS, Windows
권장: 로컬 개발은 ASan → 의심 시 Valgrind. CI는 ASan 주력, Valgrind는 스케줄 실행. 레거시 바이너리는 Valgrind만 사용.

Suppression 파일 예제 확장

아래 코드는 text를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# glibc/표준 라이브러리
{ libstdcxx_locale
  Memcheck:Leak
  match-leak-kinds: reachable
  fun:__gthread_once
  fun:_ZNSt6localeC1Ev }
# OpenSSL
{ openssl_global_init
  Memcheck:Leak
  match-leak-kinds: reachable
  obj:*/libssl.so*
  obj:*/libcrypto.so* }

의도된 “still reachable”(싱글톤 캐시 등)은 fun:OurCache::getInstance 등으로 억제. 문법 오류 시 “suppression file …is empty or malformed” 발생.

Addr1·Value4 억제

아래 코드는 text를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# Memcheck:Addr1 (잘못된 주소)
{ libxyz_invalid_read
  Memcheck:Addr1
  fun:libxyz_internal_copy
  obj:*/libxyz.so* }
# Memcheck:Value4 (미초기화, JIT false positive)
{ jit_uninit_fp
  Memcheck:Value4
  fun:jit_generated_code }

주의: 우리 코드의 진짜 버그는 억제하지 말 것.

Valgrind Memcheck 동작 흐름

아래 코드는 mermaid를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

flowchart TB
  A[malloc/new] --> B[할당 테이블 기록]
  B --> C[메모리 접근 시 검증]
  C --> D{유효?}
  D -->|Yes| E[정상 진행]
  D -->|No| F[에러 보고]
  E --> G[free/delete 시 테이블 업데이트]
  G --> C
  H[프로그램 종료] --> I[누수 검사]
  I --> J[LEAK SUMMARY 출력]

실제 디버깅 워크플로우

최소 입력으로 재현 → 2. definitely lost 우선 해결 → 3. 스택 트레이스 따라가기 ((파일:줄)에서 new/malloc 확인, 모든 경로에서 delete/free 검사) → 4. 재검증 (--error-exitcode=1로 0 확인) → 5. CI 통합

FAQ

Q. Valgrind 없이 메모리 누수를 찾을 수 있나요?

A. AddressSanitizer LeakSanitizer(-fsanitize=address,leak)로 대부분 찾을 수 있습니다. Valgrind는 재컴파일 없이, definitely/possibly/still reachable 등 세분화된 분석이 필요할 때 유리합니다.

Q. “possibly lost”는 반드시 수정해야 하나요?

A. 라이브러리 내부 realloc 등에서 나올 수 있어, 라이브러리면 suppression, 우리 코드면 원인 파악 후 수정 권장.

Q. macOS에서 Valgrind가 안 돼요.

A. macOS ARM(M1/M2)은 Valgrind 미지원. x86은 brew install valgrind 가능하나 호환성 이슈 있을 수 있음. Docker Linux 컨테이너 사용 권장.

Q. Valgrind로 테스트가 30분 타임아웃돼요.

A. 테스트 데이터 축소, --error-exitcode=1로 첫 에러에서 종료, CI에서는 ASan 주력 + Valgrind는 스케줄(매일 밤) 실행.

Q. suppression 파일이 너무 길어져요.

A. valgrind.supp, valgrind-openssl.supp 등으로 분리 후 --suppressions를 여러 번 지정: valgrind --suppressions=valgrind.supp --suppressions=valgrind-openssl.supp ./myapp

Q. Valgrind와 GDB를 함께 쓸 수 있나요?

A. valgrind --vgdb=yes --vgdb-error=0 ./myapp 실행 후 gdb ./myapp → target remote | vgdb로 연동 가능.

Q. Windows에서 Valgrind를 쓸 수 있나요?

A. Valgrind는 Linux 전용. Windows에서는 Dr. Memory 또는 Application Verifier 사용. WSL2에서 Linux 바이너리 빌드 후 Valgrind 실행도 가능.

체크리스트

Valgrind 사용 체크리스트

-g 옵션으로 컴파일
--leak-check=full --show-leak-kinds=all 사용
definitely lost 0 bytes 확인
invalid read/write 없음 확인
uninitialised value 없음 확인
외부 라이브러리 경고는 suppression 파일로 억제
CI에 --error-exitcode=1로 통합
프로덕션에서는 Valgrind 미사용

메모리 버그 예방 체크리스트

new/delete 대신 unique_ptr/shared_ptr 사용
배열은 new[]/delete[] 짝 맞추기
early return·예외 경로에서 해제 확인
버퍼 크기 검증 (strncpy, std::string, std::vector)

정리

Valgrind Memcheck로 메모리 누수·버퍼 오버런·초기화 안 된 값을 찾고, suppression 파일로 외부 라이브러리 경고를 억제하며, CI에 통합해 프로덕션 전 검증할 수 있습니다.

상황	권장
로컬 심층 디버깅	Valgrind `--leak-check=full`
CI 빠른 피드백	ASan `-fsanitize=address,leak`
외부 라이브러리 경고	Suppression 파일
프로덕션	Valgrind 사용 금지

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. Valgrind Memcheck로 메모리 누수·버퍼 오버런·초기화 안 된 값 찾기. definitely lost·invalid read/write·uninitialized value 완전 예제, suppression… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다. 다음 글: C++ RAII에서 리소스 관리 패턴을 다룹니다.

참고 자료

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

이 글의 핵심

들어가며: “메모리가 계속 늘어나는데 원인을 못 찾겠어요”

Valgrind로 3일 걸리던 버그를 10분에 찾은 이야기

목차

1. 문제 시나리오: Valgrind가 필요한 상황

시나리오 1: “서버가 2-3시간마다 죽어요”

시나리오 2: “특정 입력에서만 Segmentation fault”

시나리오 3: “결과가 가끔 이상해요”

시나리오 4: “delete 후 포인터를 또 썼어요”

시나리오 5: “외부 라이브러리에서 경고가 쏟아져요”

시나리오 6: “네트워크 서버가 클라이언트 수에 비례해 메모리가 늘어나요”

시나리오 7: “std::vector resize 후 범위 밖 접근”

시나리오 8: “멀티스레드에서 가끔만 터져요”

시나리오 9: “예외 발생 시 메모리가 해제되지 않아요”

시나리오 10: “delete[]와 delete를 혼동했어요”

원인: new[]로 할당한 메모리를 delete로 해제하면 undefined behavior. Valgrind는 Invalid free() 또는 Mismatched free()로 보고합니다. 해결: new[] ↔ delete[], new ↔ delete 짝 맞추기.

2. Valgrind 개요 및 설치

Valgrind란?

Valgrind 도구 비교

설치

컴파일 시 필수: 디버그 심볼

-O0 권장: 최적화가 심하면 인라인·재정렬로 줄 번호가 어긋날 수 있습니다.

3. Memcheck 완전 예제

기본 실행

Memcheck 핵심 옵션 요약

예제 1: 메모리 누수 (definitely lost)

4. 메모리 누수 탐지 상세

누수 종류 (Leak Kinds)

예제 2: indirectly lost

예제 3: still reachable (라이브러리)

누수 탐지 옵션 정리

5. Invalid Read/Write 탐지

예제 4: 버퍼 오버런 (Invalid write)

예제 5: 배열 인덱스 초과·vector reserve/size 혼동

예제 6: Use-after-free (Invalid read)

예제 6-2: 이중 해제 (Double free)

예제 6-3: Mismatched free (delete vs delete[])

해석: new[]로 할당했으면 반드시 delete[]로 해제해야 합니다.

6. 초기화 안 된 값(Uninitialized Value)

예제 7: 스택 변수 미초기화

예제 8: 힙 버퍼 일부 미초기화

예제 9: 구조체 멤버 미초기화

수정: 항상 초기화

7. Suppression 파일

왜 Suppression이 필요한가?

Suppression 파일 작성

Suppression 생성 (자동)

Suppression 문법 요약

Suppression 작성 시 주의사항

와일드카드(fun:*SSL*, obj:*/libssl*) 사용 가능. 여러 조건은 AND. 우리 코드의 definitely lost는 suppression 금지, 반드시 수정. 검증: valgrind --suppressions=valgrind.supp ./myapp 2>&1 | grep suppressed

8. 자주 발생하는 에러와 해결법

에러 1: “Valgrind: failed to start tool ‘memcheck’”

에러 2: “valgrind: Cannot find memory map”

에러 3: “definitely lost”가 나오는데 코드상 delete가 있어요

에러 4: “Conditional jump on uninitialised value” - false positive

에러 5: Valgrind가 너무 느려서 CI에서 타임아웃

에러 6: “still reachable”이 수천 개

에러 7: “Valgrind: invalid combination of options”

에러 8: “Fatal error: call to __builtin___strcpy_chk”

에러 9: “Valgrind: debug info not found”

에러 10: “Mismatched free() / delete / delete[]”

에러 11: “still reachable만 있는데 exit code 1”

해결: --show-leak-kinds=definite,indirect로 definitely/indirectly만 에러로 처리하거나, still reachable을 suppression으로 억제.

9. 베스트 프랙티스

Valgrind 출력 해석 가이드

10. 프로덕션 패턴 및 CI 통합

패턴 1: CMake Valgrind 타겟

패턴 2: GitHub Actions

패턴 3: 스크립트 래퍼

패턴 4: 프로덕션에서는 Valgrind 사용 금지

패턴 5: Docker (macOS ARM 대안)

패턴 6: Makefile Valgrind 타겟

패턴 7: 스케줄 기반 CI (느린 테스트)

패턴 8: 로컬용 옵션

빠른 확인: valgrind --leak-check=summary --error-exitcode=1 ./myapp 심층 분석: valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./myapp

Valgrind vs AddressSanitizer 비교

언제 무엇을 쓸까?

상세 비교표

Suppression 파일 예제 확장

Addr1·Value4 억제

원인: `new[]`로 할당한 메모리를 `delete`로 해제하면 undefined behavior. Valgrind는 Invalid free() 또는 Mismatched free()로 보고합니다. 해결: `new[]` ↔ `delete[]`, `new` ↔ `delete` 짝 맞추기.

해석: `new[]`로 할당했으면 반드시 `delete[]`로 해제해야 합니다.

와일드카드(`fun:SSL`, `obj:/libssl`) 사용 가능. 여러 조건은 AND. 우리 코드의 `definitely lost`는 suppression 금지, 반드시 수정. 검증: `valgrind --suppressions=valgrind.supp ./myapp 2>&1 | grep suppressed`

에러 8: “Fatal error: call to builtin_strcpy_chk”

해결: `--show-leak-kinds=definite,indirect`로 definitely/indirectly만 에러로 처리하거나, `still reachable`을 suppression으로 억제.

빠른 확인: `valgrind --leak-check=summary --error-exitcode=1 ./myapp`
심층 분석: `valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./myapp`