2nd/10_Wiki/Topic_Programming/DevOps_and_Security/Debugger_Techniques.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-debugger-techniques	Debugger Techniques	10_Wiki/Topics	verified	self	Debugging Debug Tooling	none	A	0.9	applied	debugging devtools troubleshooting		2026-05-10	applied	language framework Multi gdb/lldb/Chrome DevTools

Debugger Techniques

매 한 줄

"매 print 보다 breakpoint 가 빠르고, breakpoint 보다 reverse-debug 이 깊다.". Debugger techniques 는 breakpoint, watchpoint, conditional, log-point, time-travel, post-mortem (core dump) 의 매 toolkit. 2026 stack: Chrome DevTools (live), VS Code DAP, gdb/lldb, rr (record-replay), Pernosco (cloud time-travel).

매 핵심

매 Breakpoint Type

• Line: 매 source line 정지.
• Conditional: 매 expression true 일 때만.
• Log-point ("tracepoint"): 매 정지 안하고 log 찍음.
• Function: 매 fn enter.
• Watchpoint: 매 memory address change.
• Exception: 매 throw caught/uncaught.
• DOM: 매 Chrome — node modification.
• XHR/fetch: 매 URL pattern.
• Event listener: 매 click/keydown 등.

매 Time-Travel Debugging

• rr (Linux): record once, replay backwards/forwards — 매 nondeterministic bug 의 답.
• Pernosco: rr trace 의 cloud UI — 매 expression 의 모든 변경 이력.
• WinDbg TTD (Windows).
• Chrome DevTools "Replay panel" (2025+ experimental).

매 응용

1. Heisenbug — 매 conditional + log-point.
2. Crash post-mortem — 매 core dump + gdb.
3. Performance — 매 sampling + breakpoint.
4. Memory leak — 매 heap snapshot diff.
5. Distributed — 매 OpenTelemetry trace.

💻 패턴

Chrome conditional breakpoint

// 매 in DevTools right-click line → Add conditional breakpoint
// expression: user.id === 42 && cart.total > 1000
// 또는 logpoint: console.log('cart', cart, 'time', performance.now())

gdb scripted debugging

gdb --batch -x debug.gdb ./app core.12345
# debug.gdb
set pagination off
bt full
info threads
thread apply all bt
print *some_struct

lldb Python script

(lldb) script
>>> frame = lldb.frame
>>> for var in frame.variables: print(var.name, var.value)

rr record-replay (Linux)

rr record ./buggy_program
rr replay
# 매 in rr's gdb
(rr) reverse-continue
(rr) reverse-step
(rr) watch -l some_var

Node.js inspector + Chrome

node --inspect-brk=0.0.0.0:9229 server.js
# 매 chrome://inspect

Python pdb / debugpy

import pdb; pdb.set_trace()        # 매 classic
breakpoint()                       # 매 PEP 553 (python 3.7+)
# 매 VS Code remote: debugpy.listen(('0.0.0.0', 5678)); debugpy.wait_for_client()

eBPF dynamic tracing

sudo bpftrace -e 'uprobe:./app:malloc { @[ustack] = count(); }'

Conditional log-point pattern

// 매 production-safe lazy log — no perf cost when disabled
if (DEBUG) console.log('state', JSON.stringify(state));
// 매 better — feature flag gated
if (flags.debugCart) logger.debug({ cart, user });

매 결정 기준

상황	Tool
Web (Chromium)	DevTools Sources panel
Node.js	--inspect + DevTools / VS Code
C/C++ Linux	gdb / lldb + rr
C/C++ macOS	lldb + Instruments
Python	debugpy + VS Code
Heisenbug	rr + Pernosco
Production crash	core dump + gdb
Distributed	OTel trace

기본값: 매 IDE breakpoint → 부족시 rr / TTD.

🔗 Graph

• 부모: 중단점 (Breakpoints)
• 변형: 동적 런타임 분석 (Dynamic Runtime Analysis)
• 응용: Flame_Graphs · Logging_and_Error_Handling
• Adjacent: Analyze runtime performance

🤖 LLM 활용

언제: stack trace 해석, log clustering, hypothesis generation, repro script. 언제 X: 매 step-into 같은 deterministic 작업 — IDE 가 직접.

❌ 안티패턴

• printf-only: 매 build cycle 낭비 — debugger 사용.
• Production breakpoint: 매 thread freeze — log-point 사용.
• No source map: 매 minified frame 해독 불가.
• Trust gut without repro: 매 unreliable repro 면 가설 무한 반복.

🧪 검증 / 중복

• Verified: Chrome DevTools docs; gdb manual; rr-project.org; Pernosco docs.
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — breakpoint taxonomy + rr/TTD + multi-lang