segmentation fault 是操作系统因程序访问非法内存而强制终止的结果，常见于空指针解引用、数组越界、野指针、栈溢出等；需用 gdb（配合 -g 编译）查看崩溃现场，或用 valgrind 提前检测内存错误。
Segmentation Fault 是访问了不该访问的内存地址
它不是 C++ 语言错误，而是操作系统在运行时强制终止程序的结果。本质是你的代码试图读写一段当前进程无权访问的内存区域——比如已释放的堆内存、空指针解引用、栈溢出、数组越界写到只读段等。
关键点在于：它不总在出错那行立刻崩溃。可能延迟触发，也可能在完全无关的后续代码中爆发，所以不能只看报错位置。
用 gdb 启动程序并查看崩溃现场最直接
别等它崩完再查日志。直接用调试器跑起来，崩了马上停住、看栈、看寄存器、看变量：
- 编译时加
-g（如g++ -g main.cpp），否则gdb看不到源码和变量名 - 启动：
gdb ./a.out→ 运行：run→ 崩溃后立即输入bt（backtrace）看调用栈 - 若崩溃在库函数里（如
strlen或malloc内部），用up和down切换栈帧，找到你自己的代码那一层 - 用
print查变量值，特别注意指针是否为0x0、是否指向已free的地址（gdb通常会标<error: cannot access memory at address ...></error:>）
valgrind 能提前发现“还没崩但已经错了”的内存问题
gdb 只告诉你“崩在哪”，valgrind 才告诉你“哪开始错的”。它能检测非法读写、使用未初始化内存、内存泄漏、释放后使用（use-after-free）等，而且定位精确到行。
立即学习“C++免费学习笔记（深入）”；
- 运行：
valgrind --tool=memcheck --leak-check=full ./a.out - 重点看
Invalid read/write和Address is 0 bytes inside a block of size X free'd这类提示 - 注意：
valgrind会显著拖慢程序，且不支持某些系统调用（如perf_event_open），测试时关掉性能敏感逻辑 - 对多线程程序，加
--tool=helgrind检查竞态，但误报率高，优先用memcheck
常见踩坑点：数组越界、野指针、栈溢出、std::vector 的 operator[] 不检查边界
C++ 标准库很多操作默认不校验——这不是 bug，是设计取舍。你得自己负责安全边界。
-
std::vector::at()会抛std::out_of_range，但operator[]不会；手写循环遍历时用i ，别信 <code>i - 局部大数组（如
char buf[1024*1024]）容易栈溢出，改用std::vector<char>(1024*1024)</char>或new分配到堆上 -
delete后没置nullptr？下次再delete或解引用就是野指针。现代做法是用std::unique_ptr自动管理 - 传入 C 风格字符串函数（如
strcpy,printf）前，确保结尾有\0，且目标缓冲区足够大——strncpy不自动补\0是经典陷阱
真正难的不是复现 Segmentation Fault，而是它背后那个“看似正常运行了几十秒才崩”的内存腐化。一旦怀疑是 use-after-free 或 heap corruption，别猜，直接上 valgrind 或 AddressSanitizer（编译加 -fsanitize=address）。它们比人眼靠谱得多。
