블로그하는개발자

워치독 타이머란 무엇이고, 왜 필요한가요?

Linux 커널 문서는 워치독 타이머(WDT)를 소프트웨어 오류가 생겼을 때 시스템을 리셋할 수 있는 하드웨어 회로라고 설명합니다. 사용자 공간의 데몬이 일정한 간격으로 /dev/watchdog를 통해 드라이버에 알려 주고, 이 알림이 끊기면 정해진 시간 뒤에 하드웨어가 시스템을 리셋합니다.

현장에 설치되어 사람이 직접 전원을 껐다 켤 수 없는 장치에서는 프로그램이 한 번 멈추면 장치가 계속 먹통 상태로 남습니다. 워치독은 이런 멈춤이나 무한 루프를 사람 없이 복구하기 위한 마지막 안전장치입니다.

워치독은 어떻게 동작하나요?

커널 문서는 워치독이 /dev/watchdog를 여는 순간부터 동작한다고 설명합니다. 정해진 시간(문서에서는 "timeout" 또는 "margin"이라고 부릅니다) 안에 핑을 보내지 않으면 시스템이 재부팅됩니다. 가장 단순한 핑은 장치에 아무 데이터나 쓰는 것입니다.

1. 워치독이 시작되면 타이머가 카운트다운을 합니다.
2. 소프트웨어가 timeout 안에 kick(ping)을 보내면 카운트다운이 처음부터 다시 시작됩니다.
3. 프로그램이 멈춰 kick이 끊기면 카운트다운이 끝까지 진행됩니다.
4. timeout이 만료되면 하드웨어가 시스템을 리셋합니다.

kick은 어디서 해야 하나요?

면접에서 자주 나오는 함정은 타이머 ISR 안에서 무조건 kick하는 구성입니다. 이렇게 하면 메인 루프가 멈춰도 타이머 인터럽트는 계속 동작하므로 kick이 계속 들어가고, 워치독이 영원히 작동하지 않습니다.

해결 방법은 각 태스크가 자신이 정상 동작했다는 "alive" 플래그를 세우고, 메인 루프가 모든 플래그를 확인한 뒤에만 kick하고 플래그를 지우는 것입니다. 하나라도 플래그가 서지 않으면 kick하지 않으므로 워치독이 시스템을 리셋합니다.

• 잘못된 방식: 타이머 ISR에서 무조건 kick → 메인 루프가 멈춰도 계속 kick됩니다.
• 올바른 방식: 각 태스크가 alive 플래그 설정 → 메인 루프가 전부 확인 → kick 후 플래그 초기화.

Linux에서는 워치독을 어떻게 쓰나요?

• 시작과 핑: 장치를 열면 워치독이 시작됩니다. 아무 데이터나 write하는 것과 WDIOC_KEEPALIVE ioctl은 정확히 같은 동작입니다.
• Magic Close: 장치를 닫으면 보통 워치독이 멈추지만, Magic Close를 지원하는 드라이버는 닫기 직전에 매직 문자 'V'를 쓴 경우에만 워치독을 끕니다. 그렇지 않으면 데몬이 죽었다고 보고 timeout 뒤에 시스템을 재부팅합니다.
• NOWAYOUT: CONFIG_WATCHDOG_NOWAYOUT=Y(또는 nowayout 모듈 파라미터)이면 한 번 시작한 워치독을 끌 방법이 없습니다.
• timeout 설정: WDIOC_SETTIMEOUT은 초 단위로 지정하며, 드라이버는 하드웨어 단위 때문에 요청과 다를 수 있는 실제 timeout 값을 돌려줍니다. 현재 값은 WDIOC_GETTIMEOUT으로 읽습니다.
• Pretimeout: 일부 워치독은 리셋 전에 NMI/인터럽트를 발생시켜 Linux가 패닉 정보나 코어덤프를 기록하게 합니다. WDIOC_SETPRETIMEOUT은 timeout "이전"의 초 단위 값입니다. 커널 문서의 예시로는 timeout 60, pretimeout 10이면 50초 시점에 발생합니다. 모든 드라이버가 지원하지는 않습니다.
• 리셋 원인 확인: WDIOC_GETBOOTSTATUS는 마지막 부팅 시점의 상태를 돌려주며, WDIOF_CARDRESET은 직전 재부팅이 워치독 때문이었음을 뜻합니다. 모든 장치가 지원하지는 않습니다.

커널 문서는 이 API가 ad hoc 성격이라 드라이버마다 일부만 구현한다고 밝힙니다. 즉 드라이버마다 지원 범위가 다르다는 점을 기억해야 합니다. 또한 문서 머리말은 Linux 2.4.18 시점의 상태를 설명하며 마지막 검토는 2007년이라고 적혀 있으므로, 실제 사용 전에 사용하는 커널과 드라이버를 확인해야 합니다.

아래는 문서 수준의 단순화한 예시입니다(실행하지 않았으며 출력은 없습니다).

int fd = open("/dev/watchdog", O_WRONLY);

while (1) {
    ioctl(fd, WDIOC_KEEPALIVE, 0);
    sleep(10);
}

/* 정상 종료 시: 닫기 직전에 매직 문자 'V'를 씁니다. */
write(fd, "V", 1);
close(fd);

systemd 서비스는 WatchdogSec=를 쓸 수 있으며, 이 경우 서비스가 sd_notify로 WATCHDOG=1 keep-alive를 보내야 합니다. 서비스 파일 키워드는 이전 글 「systemd Type= 정리｜simple·exec·notify와 서비스 파일 핵심 키워드」를 참고해 주시기 바랍니다.

면접에서 자주 나오는 워치독 질문은 무엇인가요?

함께 보면 좋은 글은 무엇인가요?

• gdb 정리 글
• systemd Type= 정리｜simple·exec·notify와 서비스 파일 핵심 키워드

출처는 어디인가요?

• The Linux Watchdog driver API (Linux kernel docs) — 확인일 2026-10-21
• systemd.service 매뉴얼 (WatchdogSec=) — 확인일 2026-10-21

What is a watchdog timer, and why is it needed?

The Linux kernel documentation describes a watchdog timer (WDT) as a hardware circuit that can reset the system when software faults. A userspace daemon notifies the driver through /dev/watchdog at regular intervals, and if those notifications stop, the hardware resets the system after the timeout.

On a device installed in the field where nobody can power-cycle it, a single hang can leave it dead indefinitely. The watchdog is the last safety net that recovers from hangs and infinite loops without human help.

How does a watchdog work?

According to the kernel docs, the watchdog becomes active as soon as /dev/watchdog is opened, and the system reboots unless it is pinged within the period the docs call the "timeout" or "margin". The simplest ping is writing any data to the device.

1. Once started, the timer counts down.
2. If software kicks (pings) within the timeout, the countdown restarts from the beginning.
3. If the program hangs and kicks stop, the countdown runs to the end.
4. When the timeout expires, the hardware resets the system.

Where should the kick happen?

A classic interview trap is kicking unconditionally from a timer ISR. The timer interrupt keeps firing even when the main loop is stuck, so kicks keep arriving and the watchdog never fires.

The fix is to have each task set an "alive" flag, then have the main loop check all the flags, kick, and clear them. If any flag is missing, there is no kick and the watchdog resets the system.

• Wrong: kick unconditionally in the timer ISR, so kicks continue even if the main loop hangs.
• Right: each task sets its alive flag, the main loop checks all of them, then kicks and clears the flags.

How is a watchdog used on Linux?

• Start and ping: opening the device starts the watchdog. Writing any data and the WDIOC_KEEPALIVE ioctl have exactly the same effect.
• Magic Close: closing the device normally stops the watchdog, but with Magic Close the driver disables it only if the magic character 'V' was written just before closing. Otherwise it assumes the daemon died and the system reboots after the timeout.
• NOWAYOUT: with CONFIG_WATCHDOG_NOWAYOUT=Y (or the nowayout module parameter), a started watchdog cannot be disabled.
• Setting the timeout: WDIOC_SETTIMEOUT takes seconds, and the driver returns the actual timeout, which may differ because of hardware granularity. Read it back with WDIOC_GETTIMEOUT.
• Pretimeout: some watchdogs trigger an NMI or interrupt before the reset so Linux can record panic information or coredumps. WDIOC_SETPRETIMEOUT is the number of seconds before the timeout. In the kernel doc's example, a timeout of 60 and a pretimeout of 10 fires at 50. Not all drivers support it.
• Finding the reset cause: WDIOC_GETBOOTSTATUS returns the status at the last reboot, and WDIOF_CARDRESET means the last reboot was caused by the watchdog. Not all devices support it.

The kernel doc notes that the API is ad hoc and that drivers implement different parts of it, so support varies from driver to driver. Its header also says it describes the state of Linux 2.4.18 and was last reviewed in 2007, so check your own kernel and driver before relying on it.

Below is a simplified example at the doc's level (not run, no output).

int fd = open("/dev/watchdog", O_WRONLY);

while (1) {
    ioctl(fd, WDIOC_KEEPALIVE, 0);
    sleep(10);
}

/* On a clean shutdown: write the magic character 'V' just before closing. */
write(fd, "V", 1);
close(fd);

systemd services can use WatchdogSec=, in which case the service must send a WATCHDOG=1 keep-alive via sd_notify. For service-file keywords, see the earlier post "systemd Type= explained: simple, exec, notify and key service-file keywords".

What watchdog questions come up in interviews?

What related posts are worth reading?

• gdb post
• systemd Type= explained: simple, exec, notify and key service-file keywords

What are the sources?

• The Linux Watchdog driver API (Linux kernel docs) — checked 2026-10-21
• systemd.service man page (WatchdogSec=) — checked 2026-10-21

최근 Hacker News에서도 특정 모델군을 위한 추론 엔진이 큰 화제가 되었습니다. 이 글은 개념을 정리하는 글이라 설치나 실행 명령은 다루지 않습니다.

LLM 추론 프레임워크란 무엇이고, 모델 파일만으로는 왜 안 되나요?

모델 파일에는 학습된 가중치만 들어 있습니다. 이 가중치를 메모리에 올리고, 입력 문장을 토크나이저로 토큰으로 바꾸고, 토큰을 하나씩 이어서 생성하는 반복 루프를 돌리고, 결과를 요청한 쪽에 돌려주는 일은 별도의 소프트웨어가 맡아야 합니다. 이 역할을 하는 것이 추론 프레임워크입니다. vLLM 문서는 스트리밍 출력, OpenAI 호환 API 서버, Hugging Face 모델 연동을 기능으로 소개하고, llama.cpp README는 GGUF 모델 파일 사용과 OpenAI 호환 API 서버 포함을 안내합니다.

토큰과 컨텍스트 개념이 낯설다면 토큰/컨텍스트 정리 글을 먼저 보셔도 좋습니다.

서버형과 로컬형은 무엇이 다른가요?

양자화가 무엇인지는 양자화 정리 글에서 다뤘습니다. KV 캐시는 여기서 다시 설명하지 않으며, 궁금하시면 AI Day3: LLM 추론·KV 캐시를 참고해 주시기 바랍니다.

어떤 기준으로 고르나요?

• 사용자 수: 여러 사용자의 요청을 동시에 받아야 하면 서버형, 혼자 쓰면 로컬형이 자연스럽습니다.
• 하드웨어: 서버용 GPU를 쓸 수 있으면 서버형, 노트북·CPU·작은 GPU라면 로컬형이 맞습니다.
• 모델 포맷: safetensors/Hugging Face 형식이면 서버형, GGUF 파일이면 로컬형과 잘 맞습니다.
• OpenAI 호환 API: 둘 다 제공하므로 결정 요인이 아닙니다.
• 멀티 GPU: 여러 GPU로 나눠 돌려야 한다면 tensor/pipeline parallelism을 지원하는 서버형을 보시면 됩니다.

요즘 모델사가 자체 추론 엔진을 내는 이유는 무엇인가요?

2026-10-20 Hacker News에 "DeepInfer: High-performance inference framework for DeepSeek models"라는 글이 올라와 특정 모델군을 위한 추론 엔진이 화제가 되었습니다(HN 스레드). 한 모델 구조에 맞춰 최적화하면 범용 엔진보다 유리한 부분을 넣을 수 있기 때문이라고 생각해 볼 수 있습니다. 다만 이는 일반적인 추론일 뿐, 위 스레드의 내용이나 수치를 근거로 한 설명은 아닙니다.

자주 묻는 질문은 무엇인가요?

출처는 어디인가요?

함께 보면 좋은 글

• 양자화 정리 글
• 토큰/컨텍스트 정리 글
• AI Day3: LLM 추론·KV 캐시

외부 출처

• vLLM docs (확인일 2026-10-21)
• llama.cpp GitHub (확인일 2026-10-21)
• Hacker News: DeepInfer (2026-10-20 게시, 확인일 2026-10-21)

Inference engines built for a specific model family also became a big topic on Hacker News recently. This post explains the concepts, so it includes no install or run commands.

What is an LLM inference framework, and why isn't a model file enough?

A model file holds only trained weights. Separate software has to load them into memory, turn input text into tokens with a tokenizer, run the loop that generates one token after another, and return results to the caller. That is the job of an inference framework. The vLLM docs list streaming outputs, an OpenAI-compatible API server and Hugging Face model integration, while the llama.cpp README describes GGUF model files and a built-in OpenAI-compatible API server.

If tokens and context are new to you, see our token and context guide first.

How do server-style and local-style engines differ?

We covered quantization in the quantization guide. KV cache is not re-explained here; see AI Day3: LLM inference and KV cache if you are curious.

How should you choose one?

• Number of users: Serving many users at once points to server-style; just you points to local-style.
• Hardware: With server GPUs, go server-style; on a laptop, CPU or small GPU, local-style fits.
• Model format: safetensors/Hugging Face format suits server-style; GGUF files suit local-style.
• OpenAI-compatible API: Both offer one, so it is not a deciding factor.
• Multi-GPU: If you must split a model across GPUs, look at server-style engines with tensor/pipeline parallelism.

Why do model makers release their own inference engines these days?

On 2026-10-20, a Hacker News post titled "DeepInfer: High-performance inference framework for DeepSeek models" drew attention to an inference engine built for a specific model family (HN thread). The general idea is that optimizing for one model architecture can include tricks a general-purpose engine cannot. That is only general reasoning, not a claim based on the thread's content or figures.

What are the frequently asked questions?

What are the sources?

Related posts

• Quantization guide
• Token and context guide
• AI Day3: LLM inference and KV cache

External sources

• vLLM docs (checked 2026-10-21)
• llama.cpp GitHub (checked 2026-10-21)
• Hacker News: DeepInfer (posted 2026-10-20, checked 2026-10-21)

멀쩡해 보이는 멤버 변수 선언에서 expected unqualified-id before numeric constant 에러가 나면 당황스럽기 쉽습니다. 이 글은 2026-10-21(KST)에 g++ (Debian 14.2.0-19) 14.2.0으로 직접 재현한 코드와 실제 컴파일러 출력을 바탕으로 원인과 해결 방법을 정리합니다.

expected unqualified-id before numeric constant 에러란 무엇인가요?

아래는 bad.cpp입니다. 멤버 이름이 매크로 이름과 같습니다.

#define MAX_SIZE 100

struct Config {
    int MAX_SIZE = 10;   // 매크로 이름과 같은 멤버 이름
};

int main() {
    Config c;
    return c.MAX_SIZE;
}

g++ -std=c++17 -c bad.cpp의 실제 출력입니다(종료 코드 1).

$ g++ -std=c++17 -c bad.cpp
bad.cpp:1:18: error: expected unqualified-id before numeric constant
    1 | #define MAX_SIZE 100
      |                  ^~~
bad.cpp:4:9: note: in expansion of macro ‘MAX_SIZE’
    4 |     int MAX_SIZE = 10;   // 매크로 이름과 같은 멤버 이름
      |         ^~~~~~~~
bad.cpp: In function ‘int main()’:
bad.cpp:1:18: error: expected unqualified-id before numeric constant
    1 | #define MAX_SIZE 100
      |                  ^~~
bad.cpp:9:14: note: in expansion of macro ‘MAX_SIZE’
    9 |     return c.MAX_SIZE;
      |              ^~~~~~~~
bad.cpp:9:14: error: expected ‘;’ before numeric constant
    9 |     return c.MAX_SIZE;
      |              ^
      |              ;

왜 매크로 이름 충돌이 원인이 되나요?

컴파일러는 MAX_SIZE라는 이름을 보지 못하고, 전처리가 끝난 결과만 봅니다. g++ -E -P bad.cpp로 전처리 결과를 확인하면 다음과 같습니다.

$ g++ -E -P bad.cpp
struct Config {
    int 100 = 10;
};
int main() {
    Config c;
    return c. 100;
}

• 치환 전: int MAX_SIZE = 10; → 치환 후: int 100 = 10;
• 치환 전: return c.MAX_SIZE; → 치환 후: return c. 100;
• 이름이 와야 할 자리에 숫자 100이 있으니 "expected unqualified-id before numeric constant"가 됩니다.

출력은 이렇게 읽습니다.

• error는 bad.cpp:1:18, 즉 #define MAX_SIZE 100의 100을 가리킵니다. 치환된 숫자가 원래 있던 위치입니다.
• 바로 아래 note: in expansion of macro ‘MAX_SIZE’가 실제로 매크로를 쓴 자리(4:9, 9:14)를 알려줍니다. 고쳐야 할 곳은 이 note 쪽입니다.
• 세 번째 expected ‘;’ before numeric constant는 c. 100에서 이어서 나온 후속 에러로 볼 수 있습니다.

어떻게 고치나요?

1. 이름 변경: 멤버 이름을 max_size처럼 매크로와 다르게 바꿉니다.
2. constexpr로 대체: 매크로 대신 constexpr int kMaxSize = 100;을 씁니다. 상수는 일반 이름처럼 스코프 규칙을 따르므로 이런 치환이 일어나지 않습니다.
3. #undef: 충돌하는 선언 앞에서 #undef MAX_SIZE를 씁니다. 이후에 포함하는 헤더가 그 매크로를 필요로 할 수 있으니 순서에 주의해야 합니다.
4. 이름 규칙: 매크로 이름은 ALL_CAPS로 쓰고, 일반 변수·멤버 이름에는 대문자만으로 된 이름을 쓰지 않습니다.

①과 ②를 적용한 good.cpp입니다.

#define MAX_SIZE 100

struct Config {
    int max_size = 10;   // 매크로와 다른 이름 사용
};

constexpr int kMaxSize = 100;  // 매크로 대신 constexpr

int main() {
    Config c;
    return c.max_size + kMaxSize - MAX_SIZE;
}

$ g++ -std=c++17 good.cpp -o good && ./good; echo $?
10

③을 적용한 undef.cpp입니다.

#define MAX_SIZE 100

#undef MAX_SIZE
struct Config {
    int MAX_SIZE = 10;   // 매크로 이름과 같은 멤버 이름
};

int main() {
    Config c;
    return c.MAX_SIZE;
}

$ g++ -std=c++17 -c undef.cpp
$ echo $?
0

good.cpp는 컴파일되고 종료 코드 10으로 실행되었으며, undef.cpp는 컴파일에 성공했습니다(종료 코드 0).

키워드 explicit처럼 C++의 다른 함정이 궁금하시면 C++ explicit 글도 참고해 주시기 바랍니다.

헤더에서 온 매크로라면 어떻게 찾나요?

• 매크로를 직접 만들지 않았다면 note: in expansion of macro가 알려주는 위치를 먼저 확인합니다.
• g++ -E 출력을 파일로 저장해 의심되는 이름을 검색하면 치환된 결과를 바로 볼 수 있습니다. 변환된 코드를 눈으로 보는 방법으로는 C++ Insights 글도 있습니다.
• 대표적인 예가 Windows 헤더의 min/max입니다. Microsoft Learn의 "max macro (Minwindef.h)" 문서에는 #define max(a, b) (((a) > (b)) ? (a) : (b))로 정의되어 있습니다(문서 링크). 함수처럼 생긴 매크로라 std::max 같은 이름도 영향을 받을 수 있습니다.
• <windows.h>를 포함하기 전에 #define NOMINMAX를 두어 이 매크로가 정의되지 않게 하는 방법이 널리 쓰입니다.
• 다른 방법으로, (std::max)(a, b)처럼 이름을 괄호로 감싸 호출할 수도 있습니다.
• 디버깅 자체가 필요하다면 gdb 글을 참고해 주시기 바랍니다.

자주 묻는 질문은 무엇인가요?

함께 보면 좋은 글은 무엇인가요?

• C++ explicit 글
• C++ Insights로 변환된 코드 보기
• gdb 디버깅 글

출처는 어디인가요?

• GCC 직접 실행: g++ (Debian 14.2.0-19) 14.2.0, 2026-10-21 (KST)
• Microsoft Learn, max macro (Minwindef.h) (2026-10-21 확인)

Running into an expected unqualified-id before numeric constant error on a perfectly normal-looking member declaration can be confusing. This post uses code and real compiler output reproduced on 2026-10-21 (KST) with g++ (Debian 14.2.0-19) 14.2.0.

What is the "expected unqualified-id before numeric constant" error?

Here is bad.cpp, where a member has the same name as a macro.

#define MAX_SIZE 100

struct Config {
    int MAX_SIZE = 10;   // 매크로 이름과 같은 멤버 이름
};

int main() {
    Config c;
    return c.MAX_SIZE;
}

This is the real output of g++ -std=c++17 -c bad.cpp (exit code 1).

$ g++ -std=c++17 -c bad.cpp
bad.cpp:1:18: error: expected unqualified-id before numeric constant
    1 | #define MAX_SIZE 100
      |                  ^~~
bad.cpp:4:9: note: in expansion of macro ‘MAX_SIZE’
    4 |     int MAX_SIZE = 10;   // 매크로 이름과 같은 멤버 이름
      |         ^~~~~~~~
bad.cpp: In function ‘int main()’:
bad.cpp:1:18: error: expected unqualified-id before numeric constant
    1 | #define MAX_SIZE 100
      |                  ^~~
bad.cpp:9:14: note: in expansion of macro ‘MAX_SIZE’
    9 |     return c.MAX_SIZE;
      |              ^~~~~~~~
bad.cpp:9:14: error: expected ‘;’ before numeric constant
    9 |     return c.MAX_SIZE;
      |              ^
      |              ;

Why do macro name clashes cause it?

The compiler never sees the name MAX_SIZE; it only sees the preprocessed result. Running g++ -E -P bad.cpp shows it.

$ g++ -E -P bad.cpp
struct Config {
    int 100 = 10;
};
int main() {
    Config c;
    return c. 100;
}

• Before: int MAX_SIZE = 10; → after: int 100 = 10;
• Before: return c.MAX_SIZE; → after: return c. 100;
• A number sits where a name should be, which gives "expected unqualified-id before numeric constant".

Here is how to read the output.

• The error points at bad.cpp:1:18, the 100 in #define MAX_SIZE 100. That is where the substituted number was written.
• The note: in expansion of macro ‘MAX_SIZE’ right below it shows where the macro was actually used (4:9 and 9:14). That is the side you need to fix.
• The third message, expected ‘;’ before numeric constant, looks like a follow-on error from c. 100.

How do I fix it?

1. Rename: change the member to something different from the macro, such as max_size.
2. Use constexpr: write constexpr int kMaxSize = 100; instead of a macro. A constant follows normal scoping rules, so no text substitution happens.
3. #undef: put #undef MAX_SIZE before the clashing declaration. Be careful about order, because headers included later may still need that macro.
4. Naming rule: keep macros in ALL_CAPS and avoid all-caps names for ordinary variables and members.

This is good.cpp with fixes 1 and 2.

#define MAX_SIZE 100

struct Config {
    int max_size = 10;   // 매크로와 다른 이름 사용
};

constexpr int kMaxSize = 100;  // 매크로 대신 constexpr

int main() {
    Config c;
    return c.max_size + kMaxSize - MAX_SIZE;
}

$ g++ -std=c++17 good.cpp -o good && ./good; echo $?
10

This is undef.cpp with fix 3.

#define MAX_SIZE 100

#undef MAX_SIZE
struct Config {
    int MAX_SIZE = 10;   // 매크로 이름과 같은 멤버 이름
};

int main() {
    Config c;
    return c.MAX_SIZE;
}

$ g++ -std=c++17 -c undef.cpp
$ echo $?
0

good.cpp compiled and ran with exit code 10, and undef.cpp compiled successfully (exit code 0).

For another C++ pitfall, see our C++ explicit post.

How do I find a macro that comes from a header?

• If you did not write the macro yourself, start with the location given by note: in expansion of macro.
• Save the g++ -E output to a file and search for the suspect name to see the substituted result directly. To view transformed code visually, see our C++ Insights post.
• A well-known example is min/max in Windows headers. Microsoft Learn's "max macro (Minwindef.h)" page shows #define max(a, b) (((a) > (b)) ? (a) : (b)) (documentation). Because it is a function-like macro, names such as std::max can be affected too.
• It is also common practice to put #define NOMINMAX before including <windows.h> so those macros are never defined.
• Alternatively, wrap the name in parentheses when calling it: (std::max)(a, b).
• If you need to debug further, see our gdb post.

What are the frequently asked questions?

What related posts are worth reading?

• C++ explicit post
• Viewing transformed code with C++ Insights
• gdb debugging post

What are the sources?

• GCC run on my machine: g++ (Debian 14.2.0-19) 14.2.0, 2026-10-21 (KST)
• Microsoft Learn, max macro (Minwindef.h) (checked 2026-10-21)

NPU와 GPU는 각각 무엇인가요?

GPU는 원래 그래픽 처리를 위해 만들어졌습니다. 수많은 코어가 같은 연산을 동시에 병렬로 돌리는 구조이며, CUDA 같은 프로그래밍 모델 덕분에 그래픽 외에도 다양한 연산을 올릴 수 있습니다.

NPU는 신경망 연산에 맞춰 만든 전용 가속기입니다. 신경망의 대부분을 차지하는 행렬곱과 합성곱은 결국 곱하고 더해 누적하는 MAC 연산의 반복이고, NPU는 이 연산을 효율적으로 처리하도록 설계됩니다.

한 칩(SoC) 안에 CPU, GPU, NPU가 함께 들어 있는 경우도 흔합니다. 그래서 "무엇이 더 좋은가"보다 "어떤 일을 어디에 맡기는가"로 보면 이해하기 쉽습니다.

구조는 어떻게 다르고, 행렬곱·MAC 배열은 무엇인가요?

MAC(Multiply-Accumulate)은 두 값을 곱해서 누적값에 더하는 연산입니다. 행렬곱은 이 연산을 아주 많이 반복한 것입니다.

// 개념 예시(실행 안 함)
acc += a * b;

TPU v1: Google TPU v1 논문(Jouppi et al., ISCA 2017)은 "the heart of the TPU is a 65,536 8-bit MAC matrix multiply unit"이라고 설명하며, 최대 성능은 92 TOPS, 소프트웨어가 관리하는 온칩 메모리는 28 MiB라고 합니다. 데이터센터에는 2015년부터 배치되었고 추론 단계를 가속하는 장치입니다. 또 CPU와 GPU의 시간에 따라 달라지는 최적화(캐시, 비순차 실행, 멀티스레딩 등)와 달리 결정적(deterministic) 실행 모델을 쓴다고 설명합니다. TPU 자체는 TPU 글에서 따로 다룹니다.

NVIDIA Tensor Core: NVIDIA 기술 블로그(Programming Tensor Cores in CUDA 9)에 따르면 V100의 Tensor Core 하나는 4x4x4 행렬 처리 배열로 D = A * B + C를 수행합니다. A, B는 FP16이고 C, D는 FP16 또는 FP32입니다. 워프(warp)는 이를 묶어 WMMA API로 16x16x16 행렬 곱셈-누산(MMA)에 사용합니다. 또 Turing 튜닝 가이드(NVIDIA Turing Tuning Guide)에 따르면 Turing Tensor Core는 8비트, 4비트, 1비트 입력의 정수 행렬곱을 추가했고 누산은 32비트 정수로 합니다.

Arm Ethos-U55: Arm 기술 참조 설명서(Arm Ethos-U55 NPU TRM 102420)에 따르면 Ethos-U55 microNPU는 클록당 32~256개의 MAC을 구성할 수 있고, 각 MAC은 8비트 x 8비트입니다. MAC 유닛이 합성곱, 벡터 곱, 풀링의 곱셈-누산을 처리하며, Cortex-M과 함께 쓰도록 설계되었습니다.

정리하면 GPU도 Tensor Core라는 행렬 유닛을 갖고 있으므로 "GPU는 행렬 연산을 못 한다"는 말은 맞지 않습니다. 차이는 범용 프로그래밍 가능성과 행렬 유닛을 함께 가진 GPU, 그리고 MAC 배열과 온칩 메모리를 중심으로 데이터 흐름이 대부분 고정된 NPU라는 설계 초점에 있습니다.

학습과 추론에서는 어떻게 쓰임이 나뉘나요?

학습은 순전파, 역전파, 가중치 갱신을 아주 많이 반복합니다. FP16, BF16, FP32 같은 부동소수점 정밀도가 주로 쓰이고 연산 종류도 다양해서, 일반적으로 GPU가 많이 쓰입니다.

추론은 가중치를 고정한 채 순전파만 수행하므로 INT8 같은 낮은 정밀도를 쓸 수 있습니다. 그래서 스마트폰과 엣지 SoC의 많은 NPU가 추론을 목표로 합니다. 앞서 본 Ethos-U55는 8비트 MAC을 쓰고(Arm TRM), Rockchip RV1126B NPU는 "3 TOPS @ INT8"로 소개됩니다(Forlinx 제품 페이지). 자세한 내용은 아래 전력·용도 항목에서 다룹니다. TPU v1 역시 추론 가속기였습니다(TPU v1 논문).

이후의 데이터센터 가속기 중에는 학습까지 맡는 것도 있습니다. 세부 사양은 여기서 다루지 않으니 TPU 글을 참고하십시오. 양자화는 깊이 설명하지 않으며, LLM 추론 쪽은 AI 스터디 Day3 LLM 추론·KV 캐시 글을 참고하십시오.

전력과 용도로 보면 무엇을 고르면 되나요?

전력 효율 수치로는 TPU 논문(Jouppi et al., 2017)의 주장이 자주 인용됩니다. 평균적으로 당시 GPU(Nvidia K80)나 CPU(Haswell)보다 약 15X~30X 빠르고, TOPS/Watt는 약 30X~80X 높았다고 합니다. 다만 이것은 2017년 논문에서 2015년 무렵의 특정 칩과 Google 자체 워크로드를 비교한 결과이며, 일반적인 법칙이 아닙니다.

엣지 예시로 Rockchip RV1126B NPU는 Forlinx FET1126Bx-S 제품 페이지(Forlinx FET1126Bx-S)에 "3 TOPS @ INT8"로 나와 있습니다. 이 3 TOPS 수치에 스파시티 조건이 붙는다는 점은 임베디드 비전용 3TOPS급 NPU SoM 글에서 정리했습니다. 또 다른 엣지 NPU 보드는 MediaTek 10TOPS급 AIoT 보드 글에서 볼 수 있습니다.

TOPS를 볼 때는 주의가 필요합니다. 같은 TOPS라도 정밀도(INT8인지 FP16인지), 스파시티 조건, 메모리 대역폭에 따라 달라지며, 최대(peak) 수치가 실제 처리량과 같지는 않습니다. 메모리 대역폭은 HBM과 GPU 메모리 대역폭 글과 HBM5·TSMC CoWoS 검증 글에서 이어서 볼 수 있습니다.

자주 묻는 질문은 무엇인가요?

함께 보면 좋은 글은 무엇인가요?

• MediaTek 10TOPS급 AIoT 보드 글
• 임베디드 비전용 3TOPS급 NPU SoM 글
• HBM과 GPU 메모리 대역폭 글
• HBM5·TSMC CoWoS 검증 글
• TPU 글
• 삼성 파운드리와 HBM 글
• AI 스터디 Day3 LLM 추론·KV 캐시 글

출처는 어디인가요?

외부 출처 (확인일 2026-10-21)

• Jouppi et al., In-Datacenter Performance Analysis of a Tensor Processing Unit, ISCA 2017
• NVIDIA Technical Blog, Programming Tensor Cores in CUDA 9
• NVIDIA Turing Tuning Guide
• Arm Ethos-U55 NPU Technical Reference Manual
• Forlinx FET1126Bx-S product page

What are an NPU and a GPU?

A GPU was originally built for graphics. Many cores run the same operation in parallel, and programming models such as CUDA let you run many kinds of work beyond graphics.

An NPU is a dedicated accelerator for neural-network math. Most of a neural network is matrix multiply and convolution, which are repeated MAC operations, and an NPU is designed to run exactly those efficiently.

It is common for a CPU, a GPU and an NPU to sit together in one chip (SoC). So it helps to ask "which job goes where" rather than "which is better".

How is the structure different, and what are matrix multiply and a MAC array?

MAC (multiply-accumulate) multiplies two values and adds the result to a running total. Matrix multiply is that operation repeated a great many times.

// Concept example (not executed)
acc += a * b;

TPU v1: The TPU v1 paper (Jouppi et al., ISCA 2017) says "the heart of the TPU is a 65,536 8-bit MAC matrix multiply unit", with a peak of 92 TOPS and 28 MiB of software-managed on-chip memory. It has been deployed in datacenters since 2015 and accelerates the inference phase. The paper also describes a deterministic execution model, in contrast to the time-varying optimizations of CPUs and GPUs (caches, out-of-order execution, multithreading and so on). The TPU itself is covered in the TPU post (Korean).

NVIDIA Tensor Cores: According to the NVIDIA Technical Blog (Programming Tensor Cores in CUDA 9), each V100 Tensor Core is a 4x4x4 matrix processing array that performs D = A * B + C, where A and B are FP16 and C and D are FP16 or FP32. A warp uses them together for a 16x16x16 matrix multiply-accumulate (MMA) through the WMMA API. The Turing Tuning Guide (NVIDIA Turing Tuning Guide) adds that Turing Tensor Cores support integer matrix multiply with 8-bit, 4-bit and 1-bit inputs and 32-bit integer accumulation.

Arm Ethos-U55: According to the Arm technical reference manual (Arm Ethos-U55 NPU TRM 102420), the Ethos-U55 microNPU is configurable from 32 to 256 MACs per clock cycle, each an 8-bit x 8-bit MAC. The MAC unit performs the multiply-accumulate for convolution, vector products and pooling, and the NPU is designed to work with Cortex-M.

In short, GPUs now have matrix units (Tensor Cores) too, so "a GPU can't do matrix math" is wrong. The difference is design focus: a GPU combines general programmability with matrix units, while an NPU is built around a MAC array and on-chip memory with a mostly fixed dataflow.

How do training and inference split the use?

Training repeats the forward pass, backward pass and weight update many times. It usually relies on floating-point precision such as FP16, BF16 or FP32 and a wider range of operations, so GPUs are the common choice.

Inference runs only the forward pass with fixed weights, so lower precision such as INT8 can be used. That is why many NPUs in phones and edge SoCs target inference. The Ethos-U55 above uses 8-bit MACs (Arm TRM), and the Rockchip RV1126B NPU is listed at "3 TOPS @ INT8" (Forlinx product page); more on that in the next section. TPU v1 itself was an inference accelerator (TPU v1 paper).

Some later datacenter accelerators also handle training. This post does not go into specs; see the TPU post (Korean). Quantization is not explained in depth here, and for LLM inference see the AI study Day 3 post on LLM inference and the KV cache (Korean).

Which should I choose by power and use case?

For efficiency numbers, the TPU paper (Jouppi et al., 2017) is often quoted: on average the TPU was about 15X–30X faster than its contemporary GPU (Nvidia K80) or CPU (Haswell), with TOPS/Watt about 30X–80X higher. Keep in mind that this is a 2017 paper comparing specific 2015-era chips on Google's own workloads, not a general rule.

As an edge example, the Rockchip RV1126B NPU is listed at "3 TOPS @ INT8" on the Forlinx FET1126Bx-S product page (Forlinx FET1126Bx-S). That the 3 TOPS figure is tied to a sparsity condition is covered in the post on a 3-TOPS-class NPU SoM for embedded vision (Korean). Another edge NPU board appears in the post on a MediaTek 10-TOPS-class AIoT board (Korean).

Be careful with TOPS. The same TOPS figure changes with precision (INT8 versus FP16), sparsity conditions and memory bandwidth, and peak throughput is not real throughput. For memory bandwidth, continue with the post on HBM and GPU memory bandwidth and the HBM5 and TSMC CoWoS verification post (both Korean).

What are the frequently asked questions?

What should I read next?

• MediaTek 10-TOPS-class AIoT board post
• 3-TOPS-class NPU SoM for embedded vision post
• HBM and GPU memory bandwidth post
• HBM5 and TSMC CoWoS verification post
• TPU post
• Samsung Foundry and HBM post
• AI study Day 3: LLM inference and KV cache post

What are the sources?

External sources (checked 2026-10-21)

• Jouppi et al., In-Datacenter Performance Analysis of a Tensor Processing Unit, ISCA 2017
• NVIDIA Technical Blog, Programming Tensor Cores in CUDA 9
• NVIDIA Turing Tuning Guide
• Arm Ethos-U55 NPU Technical Reference Manual
• Forlinx FET1126Bx-S product page

Grok 4.8에 대해 공식적으로 알려진 것은 무엇인가요?

• 게시글 1 (X 게시글, 2026-09-14 10:24 KST / 2026-09-14 01:24 UTC): @techdevnotes가 "Apart from Grok 4.7, what are we even expecting from SpaceXAI in september"라고 묻자 일론 머스크가 답글로 남겼습니다.
  • 원문: "Grok 4.8, which is a 2.5T model trained with our new C++ software stack, will finish training this week and start RL"
• 게시글 2 (X 게시글, 2026-09-14 20:19 KST): "Grok 4.8 will be a noticeable improvement."
• 알려지지 않은 것: 공식 모델 카드, 밀집(dense)인지 MoE인지에 대한 구성, 벤치마크, 가격, 출시일은 없습니다. 그 주에 학습이 실제로 끝났는지도 공식적으로 확인되지 않았습니다.

2.5T 파라미터는 메모리로 얼마나 큰가요?

감 잡기(대략 추정)입니다. 가중치만 계산하고, 10진수 GB 단위, 80GB급 GPU를 가정합니다. xAI의 실제 구성이 아닙니다.

• 2.5T = 2.5 × 10^12 개 파라미터
• BF16/FP16 (파라미터당 2바이트): 2.5 × 10^12 × 2 B = 5.0 TB = 5,000 GB → 5,000 ÷ 80 = 62.5 → 가중치 보관만으로 최소 약 63장
• FP8 (1바이트): 2.5 TB = 2,500 GB → 2,500 ÷ 80 = 31.25 → 약 32장
• INT4 (0.5바이트): 1.25 TB = 1,250 GB → 1,250 ÷ 80 = 15.6 → 약 16장
• KV 캐시, 활성값, 프레임워크 오버헤드, 병렬화에 따른 중복은 제외한 값이므로 실제 배포에는 더 많이 필요합니다.
• 학습은 훨씬 무겁습니다. 혼합 정밀도 Adam은 파라미터당 대략 16바이트를 쓴다고 알려져 있습니다(fp16 가중치 2 + fp16 그래디언트 2 + fp32 마스터 가중치 4 + Adam m 4 + v 4, ZeRO 논문, Rajbhandari et al., 2019). 2.5 × 10^12 × 16 B = 40 TB = 40,000 GB → 40,000 ÷ 80 = 500장으로, 활성값을 빼고 모델 상태만 담아도 이 정도입니다. 이 역시 감 잡기이며 xAI의 실제 학습 구성은 공개되지 않았습니다.
• MoE 구조인지는 알려지지 않았습니다. 만약 MoE라면 토큰당 연산량은 줄어도 모든 전문가(expert) 가중치는 여전히 메모리에 올려야 합니다.
• 정밀도를 낮춰 메모리를 줄이는 원리는 양자화 정리 글을 참고해 주시기 바랍니다.

"학습을 끝내고 RL을 시작한다"는 무슨 뜻인가요?

• 사전학습(pretraining): 방대한 텍스트에서 다음 토큰을 맞추는 자기지도 학습입니다.
• SFT: 지시와 응답 예시로 미세 조정하는 단계입니다.
• RL(강화학습): 선호 모델의 보상, 또는 테스트 통과·수학 정답 같은 검증 가능한 보상으로 모델을 개선합니다. RLHF는 PPO 계열 업데이트를 쓰고, DPO는 선호 데이터만 쓰는 대안입니다.
• 따라서 "학습을 끝내고 RL을 시작한다"는 사전학습 단계가 끝나고 후속 학습이 시작된다는 의미로 읽을 수 있습니다. 일반적으로 출시는 RL, 평가, 안전성 테스트 이후에 이뤄지지만, 이것도 일반론이며 xAI의 발표가 아닙니다.
• 사전학습·SFT·RLHF의 구분은 관련 정리 글에서 확인하실 수 있습니다.

학습 스택을 C++로 쓰는 이유는 무엇일까요?

• 핫 패스의 오버헤드: Python 인터프리터와 GIL 오버헤드를 연산 중심 경로에서 피할 수 있습니다.
• 정밀한 메모리 제어: 할당자, 고정(pinned) 메모리, 단편화 회피를 직접 다룰 수 있어 2.5T 규모에서 유리할 수 있습니다.
• CUDA·커널 직접 연동: 융합 커널(fused kernel)을 통합하기 쉽습니다.
• 결정적 자원 관리: RAII로 자원 수명을 명확히 관리할 수 있습니다.
• 통신·서빙과의 연동: NCCL 같은 통신 라이브러리, 추론 서버와의 연동이 수월합니다.
• 참고로 PyTorch 같은 기존 프레임워크도 핵심은 C++(ATen/libtorch)이고 Python은 프런트엔드입니다.

10월 19일 기준 Grok 4.8은 출시됐나요?

• 확인일: 2026-10-19 약 01:00 KST
• x.ai/news: 가장 최근 항목은 "Introducing Grok Voice 3.0"(2026-10-14)이며 Grok 4.8 발표는 없습니다.
• docs.x.ai 모델 목록: 가장 새로운 텍스트 모델은 grok-4.7이며 grok-4.8은 없습니다. 페이지에는 "use Grok 4.7. It is the most capable model we've built."라고 적혀 있습니다.
• Grok 4.7은 2026-09-21에 출시된 최신 주력 모델입니다. 독립 매체 versusapp.com(2026-10-16)도 같은 날짜를 전합니다.
• 출시 시점: 공개된 출시일은 없습니다. 시점을 점치는 것은 추측에 불과하므로 이 글에서는 다루지 않겠습니다.

자주 묻는 질문은 무엇인가요?

출처는 어디인가요?

• Elon Musk, X 게시글 (2026-09-14 10:24 KST)
• Elon Musk, X 게시글 (2026-09-14 20:19 KST)
• xAI News (2026-10-19 확인)
• xAI Docs: Models (2026-10-19 확인)
• versusapp.com, Grok 4.8 release date (2026-10-16)
• Rajbhandari et al., ZeRO (2019)

What is officially known about Grok 4.8?

• Post 1 (X post, 2026-09-14 10:24 KST / 2026-09-14 01:24 UTC): Replying to @techdevnotes, who asked "Apart from Grok 4.7, what are we even expecting from SpaceXAI in september", Musk wrote:
  • "Grok 4.8, which is a 2.5T model trained with our new C++ software stack, will finish training this week and start RL"
• Post 2 (X post, 2026-09-14 20:19 KST): "Grok 4.8 will be a noticeable improvement."
• Not known: There is no official model card, no word on whether it is dense or MoE, and no benchmarks, price or release date. There is also no official confirmation that training actually finished that week.

How big is 2.5T parameters in memory?

This is a rough estimate: weights only, decimal GB, 80 GB-class GPUs. It is not xAI's actual setup.

• 2.5T = 2.5 × 10^12 parameters
• BF16/FP16 (2 bytes per parameter): 2.5 × 10^12 × 2 B = 5.0 TB = 5,000 GB → 5,000 ÷ 80 = 62.5 → at least ~63 GPUs just to hold the weights
• FP8 (1 byte): 2.5 TB = 2,500 GB → 2,500 ÷ 80 = 31.25 → ~32 GPUs
• INT4 (0.5 byte): 1.25 TB = 1,250 GB → 1,250 ÷ 80 = 15.6 → ~16 GPUs
• These exclude KV cache, activations, framework overhead and duplication from parallelism, so real deployments need more.
• Training is much heavier. Mixed-precision Adam keeps roughly 16 bytes per parameter (fp16 weights 2 + fp16 grads 2 + fp32 master weights 4 + Adam m 4 + v 4), per the ZeRO paper (Rajbhandari et al., 2019). 2.5 × 10^12 × 16 B = 40 TB = 40,000 GB → 40,000 ÷ 80 = 500 GPUs for model states alone, before activations. This is also a rough estimate; xAI's actual training setup is not public.
• Whether the model is MoE is unknown. If it is, all expert weights still need memory even though compute per token is lower.
• For how lower precision shrinks memory, see our quantization post.

What does "finish training and start RL" mean?

• Pretraining: Self-supervised next-token prediction on huge amounts of text.
• SFT: Fine-tuning on instruction–response examples.
• RL: Improving the model with rewards from preference models or verifiable rewards such as tests passing or correct math answers. RLHF uses PPO-style updates; DPO is a preference-only alternative.
• So "finish training and start RL" can be read as the pretraining phase ending and post-training beginning. A release usually comes later, after RL, evaluation and safety testing, but this too is general knowledge, not an xAI statement.
• For the difference between pretraining, SFT and RLHF, see our related post.

Why might a training stack be written in C++?

• Hot-path overhead: It avoids Python interpreter and GIL overhead on the performance-critical path.
• Precise memory control: Direct control over allocators, pinned memory and fragmentation can matter at 2.5T scale.
• Direct CUDA and kernel integration: Fused kernels are easier to integrate.
• Deterministic resource management: RAII makes resource lifetimes explicit.
• Interop: Easier integration with communication libraries such as NCCL and with inference servers.
• Note that existing frameworks such as PyTorch already have C++ cores (ATen/libtorch) with a Python front end.

Has Grok 4.8 been released as of October 19?

• Check date: 2026-10-19, about 01:00 KST
• x.ai/news: The latest entry is "Introducing Grok Voice 3.0" (2026-10-14); there is no Grok 4.8 announcement.
• docs.x.ai model list: The newest text model listed is grok-4.7, with no grok-4.8. The page says "use Grok 4.7. It is the most capable model we've built."
• Grok 4.7 is the latest main model, released on 2026-09-21. The independent outlet versusapp.com (2026-10-16) reports the same date.
• Release timing: No release date has been announced. Any guess would be pure speculation, so this post does not offer one.

What are the most frequently asked questions?

What are the sources?

• Elon Musk, X post (2026-09-14 10:24 KST)
• Elon Musk, X post (2026-09-14 20:19 KST)
• xAI News (checked 2026-10-19)
• xAI Docs: Models (checked 2026-10-19)
• versusapp.com, Grok 4.8 release date (2026-10-16)
• Rajbhandari et al., ZeRO (2019)

valgrind란? memcheck는 무엇을 잡나요?

• 기본 도구 Memcheck와 빌드 옵션: valgrind를 별도 도구 지정 없이 실행하면 기본 메모리 오류 탐지기인 Memcheck가 동작합니다. Valgrind Quick Start 가이드에 따르면 프로그램을 다시 컴파일하지 않아도 기존 바이너리를 바로 실행할 수 있습니다. 다만 리포트에서 정확한 소스 파일과 줄 번호를 확인하려면 -g 플래그를 켜고, 최적화로 인해 줄 번호가 흐려지지 않도록 -O0으로 빌드하는 것이 좋습니다.
• 주요 탐지 항목:
  • 잘못된 메모리 읽기·쓰기 (Invalid reads/writes): 할당된 힙 블록 범위를 벗어난 접근 등을 찾아냅니다.
  • 초기화되지 않은 값 사용 (Use of uninitialised values): 초기화하지 않은 변수를 조건문 분기 등에 사용할 때 경고를 출력합니다. 여기에 --track-origins=yes 옵션을 추가하면 Memcheck 매뉴얼 설명대로 실행 속도는 더 느려지지만("makes Memcheck run slower"), 초기화되지 않은 값이 어디서 만들어졌는지(origin)까지 보여줍니다.
  • 메모리 누수 (Memory leaks): 프로그램 종료 시점까지 해제되지 않은 힙 블록을 손실 유형별로 분류해 보고합니다.
  • 잘못된 해제 (Bad frees): 잘못된 포인터 해제나 중복 해제 등을 감지합니다.
• 크래시 지점을 대화형으로 멈춰 변수와 콜스택을 직접 확인하려면 gdb 디버깅 정리 글을 참고하시기 바랍니다.

valgrind로 메모리 누수는 어떤 순서로 찾나요?

Step 1: -g -O0 빌드 및 valgrind 실행 명령

실제 실행 결과 (Debian, gcc 14.2.0, valgrind-3.24.0)

$ gcc -g -O0 -o leak leak.c
$ valgrind --leak-check=full --track-origins=yes ./leak

Step 2: 테스트 코드 (leak.c)

직접 누수(definitely lost), 간접 누수(indirectly lost), 초기화되지 않은 지역 변수 분기, 힙 범위 밖 쓰기(invalid write)를 한 번에 확인하기 위한 leak.c 코드입니다.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct node { char *name; };

int main(void) {
    char *a = malloc(16);              /* never freed -> definitely lost */
    strcpy(a, "hello");

    struct node *n = malloc(sizeof *n); /* pointer dropped -> definitely lost */
    n->name = malloc(32);               /* only reachable via n -> indirectly lost */

    int x;                              /* uninitialised */
    if (x > 0) puts("positive");

    int *arr = malloc(4 * sizeof *arr);
    arr[4] = 1;                         /* invalid write, 1 past end */
    free(arr);

    a = NULL; n = NULL;
    return 0;
}

Step 3: Memcheck 출력 확인

실제 실행 결과 (Debian, gcc 14.2.0, valgrind-3.24.0; 프로세스 번호는 PID로 표기)

==PID== Memcheck, a memory error detector
==PID== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==PID== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==PID== Command: ./leak
==PID== 
==PID== Conditional jump or move depends on uninitialised value(s)
==PID==    at 0x1091A5: main (leak.c:15)
==PID==  Uninitialised value was created by a stack allocation
==PID==    at 0x109159: main (leak.c:7)
==PID== 
==PID== Invalid write of size 4
==PID==    at 0x1091CC: main (leak.c:18)
==PID==  Address 0x4a5e150 is 0 bytes after a block of size 16 alloc'd
==PID==    at 0x4844818: malloc (vg_replace_malloc.c:446)
==PID==    by 0x1091BF: main (leak.c:17)
==PID== 
==PID== 
==PID== HEAP SUMMARY:
==PID==     in use at exit: 56 bytes in 3 blocks
==PID==   total heap usage: 4 allocs, 1 frees, 72 bytes allocated
==PID== 
==PID== 16 bytes in 1 blocks are definitely lost in loss record 1 of 3
==PID==    at 0x4844818: malloc (vg_replace_malloc.c:446)
==PID==    by 0x10916A: main (leak.c:8)
==PID== 
==PID== 40 (8 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3
==PID==    at 0x4844818: malloc (vg_replace_malloc.c:446)
==PID==    by 0x109188: main (leak.c:11)
==PID== 
==PID== LEAK SUMMARY:
==PID==    definitely lost: 24 bytes in 2 blocks
==PID==    indirectly lost: 32 bytes in 1 blocks
==PID==      possibly lost: 0 bytes in 0 blocks
==PID==    still reachable: 0 bytes in 0 blocks
==PID==         suppressed: 0 bytes in 0 blocks
==PID== 
==PID== For lists of detected and suppressed errors, rerun with: -s
==PID== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

Step 4: 출력 읽는 법과 누수 4가지 분류

• 실행 중 메모리 오류 2건:
  • leak.c:15: 초기화되지 않은 변수 x를 조건문에서 사용해 Conditional jump or move depends on uninitialised value(s)가 기록되었습니다. --track-origins=yes 옵션 덕분에 해당 값이 main (leak.c:7)의 스택 할당에서 생성되었음을 함께 알려줍니다.
  • leak.c:18: leak.c:17에서 할당한 16바이트 블록 바로 뒤(0 bytes after a block of size 16 alloc'd)에 4바이트를 쓰는 Invalid write of size 4가 잡혔습니다.
• 누수 기록 해석:
  • 16 bytes in 1 blocks are definitely lost: leak.c:8에서 할당한 포인터 a가 해제 없이 소실된 기록입니다.
  • 40 (8 direct, 32 indirect) bytes in 1 blocks are definitely lost: leak.c:11에서 할당한 struct node 구조체 8바이트가 직접 손실(direct)되었고, 그 내부 멤버 n->name이 가리키던 32바이트 버퍼가 간접 손실(indirect)되었음을 뜻합니다.
• LEAK SUMMARY 4가지 구분 (Memcheck 매뉴얼 기준):
  • definitely lost: 해당 블록을 가리키는 포인터가 전혀 남아 있지 않아 접근할 수 없는 누수입니다(최우선 수정 대상입니다).
  • indirectly lost: 이미 잃어버린(definitely lost) 블록을 통해서만 도달할 수 있는 블록입니다(루트 블록을 해제하면 함께 해결됩니다).
  • possibly lost: 블록의 시작점이 아니라 블록 내부 중간을 가리키는 포인터(interior pointer)만 남아 있는 경우입니다.
  • still reachable: 프로그램 종료 시점까지 시작점을 가리키는 포인터가 남아 있어 접근 가능한 블록입니다.

valgrind와 ASan은 무엇이 다르고, 언제 무엇을 쓰나요?

동일한 leak.c 파일을 AddressSanitizer(ASan)로 빌드해 실행한 결과는 다음과 같습니다.

실제 실행 결과 (Debian, gcc 14.2.0 ASan, -O0; 처음 14줄, 실행마다 주소는 달라질 수 있음)

$ gcc -g -O0 -fsanitize=address -fno-omit-frame-pointer -o leak_asan leak.c
$ ./leak_asan

==PID===============================================================
==PID==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000000060 at pc 0x556bd471129f bp 0x7ffd7fc4d6d0 sp 0x7ffd7fc4d6c8
WRITE of size 4 at 0x502000000060 thread T0
    #0 0x556bd471129e in main /tmp/vg/leak.c:18
    #1 0x7f67cf987ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #2 0x7f67cf987d64 in __libc_start_main_impl ../csu/libc-start.c:360
    #3 0x556bd4711100 in _start (/tmp/vg/leak_asan+0x1100) (BuildId: 835c3ecb59641265ff392653a6debb124f0659a0)

0x502000000060 is located 0 bytes after 16-byte region [0x502000000050,0x502000000060)
allocated by thread T0 here:
    #0 0x7f67cfc46c57 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x556bd471125b in main /tmp/vg/leak.c:17
    #2 0x7f67cf987ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

• 실행 결과 비교:
  • 첫 오류에서 즉시 종료: ASan은 leak.c:18의 heap-buffer-overflow를 발견한 즉시 프로세스를 종료(exit code 1)하므로, 프로그램 종료 시점에 동작하는 누수 리포트(LeakSanitizer)가 이번 실행에서는 출력되지 않았습니다. 반면 valgrind는 오류를 기록한 뒤 끝까지 실행해 누수 요약까지 한 번에 출력합니다.
  • 초기화되지 않은 값 미탐지: ASan은 leak.c:15의 초기화되지 않은 변수(x) 읽기를 보고하지 않았습니다. Clang AddressSanitizer 공식 문서에 명시된 것처럼 초기화되지 않은 메모리 읽기 탐지는 ASan이 아니라 MemorySanitizer(또는 valgrind Memcheck)의 영역입니다.
  • 최적화 옵션 관찰 메모: 이번 실행에서는 동일한 코드를 -O1으로 ASan 빌드했을 때 컴파일러가 결과에 영향을 주지 않는(dead) malloc/쓰기/free를 제거해 아무런 오류도 출력되지 않았습니다. 재현용 테스트 코드에서는 -O0으로 확인하는 편이 안전합니다(ASan 자체의 세부 설정은 이전 AddressSanitizer 글을 참고하시기 바랍니다).

임베디드 보드에서 쓸 때 주의할 점은 무엇인가요?

• Linux 유무와 아키텍처 지원 확인: Valgrind 공식 플랫폼 문서에 따르면 Linux 환경에서 ARM/Linux(supported since ARMv7), ARM64/Linux(ARMv8), RISCV64/Linux, MIPS32/Linux 및 MIPS64/Linux를 지원하며, X86/Linux는 유지보수 모드(in maintenance mode)입니다. OS 없이 동작하는 Cortex-M 베어메탈 MCU에는 valgrind를 적용할 수 없으므로, 반드시 Linux가 도는 보드 범위에서만 사용합니다.
• Buildroot / Yocto 이미지에 포함하기:
  • Buildroot: 설정에서 BR2_PACKAGE_VALGRIND=y 옵션을 활성화합니다.
  • Yocto: 이미지 레시피의 IMAGE_INSTALL에 valgrind를 추가합니다(예: IMAGE_INSTALL:append = " valgrind").
• 보드 메모리 여유와 호스트 검증 대안:
  • 소형 임베디드 보드에서는 valgrind 실행 시 추가 RAM이 필요하므로 보드의 가용 메모리가 충분한지 먼저 확인해야 합니다.
  • 호스트 PC에서 qemu-user로 ARM 바이너리를 실행하는 방식도 거론되지만, qemu-user 내부에 valgrind를 겹쳐 올리는 구성은 쉽지 않습니다. 하드웨어 종속 계층을 분리할 수 있다면 해당 로직을 x86 호스트 빌드로 재현해 호스트에서 valgrind나 ASan으로 먼저 검증하는 방법이 가장 단순합니다.

valgrind에 대해 자주 묻는 질문은 무엇인가요?

What is valgrind, and what does Memcheck detect?

• Default tool Memcheck and build flags: Running valgrind invokes Memcheck by default. As noted in the Valgrind Quick Start Guide, it works directly on an existing binary with no recompile required, though building with -g (and -O0 recommended for accurate lines) lets Memcheck point to exact source files and line numbers.
• What Memcheck catches:
  • Invalid reads and writes: Out-of-bounds accesses on heap blocks and invalid pointer dereferences.
  • Use of uninitialised values: Conditional jumps or moves that depend on uninitialised variables. Passing --track-origins=yes "makes Memcheck run slower" (Memcheck manual) but pinpoints where the uninitialised value came from.
  • Memory leaks: Heap blocks left allocated at program exit, grouped by loss category.
  • Bad frees: Invalid or mismatched deallocations.
• If you want to pause execution interactively at a crash site to inspect variables and the call stack, see our gdb debugging guide.

In what order do you find memory leaks with valgrind?

Step 1: Build with -g -O0 and run valgrind

Actual output (Debian, gcc 14.2.0, valgrind-3.24.0)

$ gcc -g -O0 -o leak leak.c
$ valgrind --leak-check=full --track-origins=yes ./leak

Step 2: Test code (leak.c)

This leak.c sample triggers a direct leak (definitely lost), an indirect leak (indirectly lost), a branch on an uninitialised stack variable, and a heap out-of-bounds write.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct node { char *name; };

int main(void) {
    char *a = malloc(16);              /* never freed -> definitely lost */
    strcpy(a, "hello");

    struct node *n = malloc(sizeof *n); /* pointer dropped -> definitely lost */
    n->name = malloc(32);               /* only reachable via n -> indirectly lost */

    int x;                              /* uninitialised */
    if (x > 0) puts("positive");

    int *arr = malloc(4 * sizeof *arr);
    arr[4] = 1;                         /* invalid write, 1 past end */
    free(arr);

    a = NULL; n = NULL;
    return 0;
}

Step 3: Inspect the Memcheck output

Actual output (Debian, gcc 14.2.0, valgrind-3.24.0; process ID replaced with PID)

==PID== Memcheck, a memory error detector
==PID== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==PID== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==PID== Command: ./leak
==PID== 
==PID== Conditional jump or move depends on uninitialised value(s)
==PID==    at 0x1091A5: main (leak.c:15)
==PID==  Uninitialised value was created by a stack allocation
==PID==    at 0x109159: main (leak.c:7)
==PID== 
==PID== Invalid write of size 4
==PID==    at 0x1091CC: main (leak.c:18)
==PID==  Address 0x4a5e150 is 0 bytes after a block of size 16 alloc'd
==PID==    at 0x4844818: malloc (vg_replace_malloc.c:446)
==PID==    by 0x1091BF: main (leak.c:17)
==PID== 
==PID== 
==PID== HEAP SUMMARY:
==PID==     in use at exit: 56 bytes in 3 blocks
==PID==   total heap usage: 4 allocs, 1 frees, 72 bytes allocated
==PID== 
==PID== 16 bytes in 1 blocks are definitely lost in loss record 1 of 3
==PID==    at 0x4844818: malloc (vg_replace_malloc.c:446)
==PID==    by 0x10916A: main (leak.c:8)
==PID== 
==PID== 40 (8 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3
==PID==    at 0x4844818: malloc (vg_replace_malloc.c:446)
==PID==    by 0x109188: main (leak.c:11)
==PID== 
==PID== LEAK SUMMARY:
==PID==    definitely lost: 24 bytes in 2 blocks
==PID==    indirectly lost: 32 bytes in 1 blocks
==PID==      possibly lost: 0 bytes in 0 blocks
==PID==    still reachable: 0 bytes in 0 blocks
==PID==         suppressed: 0 bytes in 0 blocks
==PID== 
==PID== For lists of detected and suppressed errors, rerun with: -s
==PID== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

Step 4: How to read the report and the four leak kinds

• Two runtime memory errors:
  • leak.c:15: Reports Conditional jump or move depends on uninitialised value(s) for x, and because --track-origins=yes was enabled, traces its origin to the stack allocation in main (leak.c:7).
  • leak.c:18: Reports Invalid write of size 4 located 0 bytes after a block of size 16 alloc'd at leak.c:17.
• Leak records:
  • 16 bytes in 1 blocks are definitely lost: The buffer a allocated at leak.c:8.
  • 40 (8 direct, 32 indirect) bytes in 1 blocks are definitely lost: The 8-byte struct node allocated at leak.c:11 is directly lost, and its 32-byte n->name buffer is indirectly lost along with it.
• The four LEAK SUMMARY kinds (Memcheck manual):
  • definitely lost: No pointer to the block remains anywhere—fix these first.
  • indirectly lost: The block is only reachable through another lost block—freeing the root block resolves these automatically.
  • possibly lost: Only interior pointers (pointing into the middle of the block rather than its start) remain.
  • still reachable: A pointer to the start of the block still exists at exit.

How do valgrind and ASan differ, and when should you use each?

Here is what happens when we compile and run the exact same leak.c file with AddressSanitizer (ASan):

Actual output (Debian, gcc 14.2.0 ASan, -O0; first 14 lines, addresses vary across runs)

$ gcc -g -O0 -fsanitize=address -fno-omit-frame-pointer -o leak_asan leak.c
$ ./leak_asan

==PID===============================================================
==PID==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000000060 at pc 0x556bd471129f bp 0x7ffd7fc4d6d0 sp 0x7ffd7fc4d6c8
WRITE of size 4 at 0x502000000060 thread T0
    #0 0x556bd471129e in main /tmp/vg/leak.c:18
    #1 0x7f67cf987ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #2 0x7f67cf987d64 in __libc_start_main_impl ../csu/libc-start.c:360
    #3 0x556bd4711100 in _start (/tmp/vg/leak_asan+0x1100) (BuildId: 835c3ecb59641265ff392653a6debb124f0659a0)

0x502000000060 is located 0 bytes after 16-byte region [0x502000000050,0x502000000060)
allocated by thread T0 here:
    #0 0x7f67cfc46c57 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x556bd471125b in main /tmp/vg/leak.c:17
    #2 0x7f67cf987ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

• Comparing the two runs:
  • Stops at the first error: ASan aborts immediately at the first error (heap-buffer-overflow at leak.c:18, exit code 1), so LeakSanitizer did not report the memory leaks in this run. By contrast, valgrind logs each error and continues running to print the leak summary at exit.
  • Does not flag uninitialised reads: ASan did not report the uninitialised read at leak.c:15. As documented in the Clang AddressSanitizer documentation, uninitialised reads are the job of MemorySanitizer (or valgrind Memcheck), not ASan.
  • Observation on optimisation flags: In this run, compiling the same ASan build with -O1 printed nothing because the compiler eliminated the dead malloc/write/free calls. Stick to -O0 for small reproduction snippets (for general ASan flags, see our earlier AddressSanitizer post).

What should you watch out for on embedded boards?

• Linux requirement and architecture support: According to the official Valgrind platforms page, supported Linux targets include ARM/Linux (supported since ARMv7), ARM64/Linux (ARMv8), RISCV64/Linux, and MIPS32/64/Linux, while X86/Linux is in maintenance mode. Bare-metal Cortex-M MCUs without Linux cannot run valgrind—it is strictly for boards running Linux.
• Adding valgrind to Buildroot or Yocto:
  • Buildroot: Enable BR2_PACKAGE_VALGRIND=y in your configuration.
  • Yocto: Add valgrind to IMAGE_INSTALL (for example, IMAGE_INSTALL:append = " valgrind").
• Board RAM and host alternatives:
  • On small boards, valgrind needs extra RAM, so check free memory before running it on target.
  • While running an ARM binary under qemu-user on the host is sometimes suggested, layering valgrind inside qemu-user is not straightforward. The simplest alternative is to compile and reproduce the platform-independent logic on your x86 host build with valgrind or ASan.

What are frequently asked questions about valgrind?