崩溃时堆栈只显示std::vector::operator[]，说明访问越界或指针已失效；根本原因是多线程下未同步的赋值（如=、clear）导致shared_vector处于中间态，应重点排查非const操作、跨线程读写竞争及裸指针缓存。
崩溃时堆栈只显示 std::vector::operator[] 怎么办
这种堆栈几乎没用——它只告诉你“在访问 vector 元素时崩了”，但不告诉你谁改坏了 shared_vector 的内部指针或 size。根本原因往往是另一个线程正在执行赋值（如 shared_vector = small_vector），而当前线程恰好读到中间态：shared_vector.data() 指向已释放内存，或 shared_vector.size() 被写乱。
此时别急着翻源码找 operator[] 实现，重点查三处：
- 所有对
shared_vector的非 const 成员调用（=、clear()、resize()、swap()） - 所有未加锁的跨线程读写位置，尤其注意“写操作在头，读操作在尾”的错位场景
- 是否混用了
std::vector和裸指针（如data()返回值被长期缓存）
gdb 中看到 frame #0 是 0x0000000000000000 怎么分析
这代表程序试图调用一个空函数指针，或访问 nullptr 对象的成员函数。多线程下典型路径是：线程 A 执行 delete p，线程 B 同时执行 p->method()，而 p 此刻已成悬垂指针。
关键不是看崩溃点，而是查 p 的生命周期：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
info registers看寄存器中哪个寄存器存的是0x0，再结合反汇编确认它原本应指向什么对象 - 用
thread apply all bt查所有线程堆栈，特别关注是否有线程刚执行完delete或std::shared_ptr::~shared_ptr - 检查该对象是否由
new分配但未用智能指针管理；或是否被std::move后又被二次使用
为什么 AddressSanitizer 报错位置和崩溃堆栈对不上
ASan 捕获的是非法内存访问的“第一现场”，而 gdb 崩溃堆栈是“最终崩溃点”。例如：线程 A 在第 100 次循环中把 shared_vector 的 capacity 字段写成了 0，ASan 在那一刻就报错；但程序还能跑几十轮，直到线程 B 尝试 push_back 触发 realloc 失败才真正崩溃。
所以必须信任 ASan 的报告行号，而不是 gdb 的 bt：
- 启用 ASan 时务必加
-fno-omit-frame-pointer，否则行号可能偏移 - 若 ASan 报
heap-use-after-free，直接定位到delete那行，再顺藤摸瓜找谁还在用它 - 若报
stack-buffer-overflow，检查局部std::array或 C 风格数组是否被越界写，这类错误常因线程间数据长度假设不一致导致
ThreadSanitizer 显示 data race 却找不到对应锁保护
TSan 的报告里会明确写出“write at line X”和“read at line Y”，但这两行代码可能看起来毫无关系——比如写操作在 shared_vector.assign(...)，读操作在 shared_vector[0]。问题不在语法，而在语义：vector 的赋值是“先释放旧内存、再拷贝新内容、最后更新 size/ptr”，整个过程不是原子的。
修复不能只靠加锁，得从数据结构层面切断并发风险：
- 避免共享可变容器，改用
std::shared_ptr<:vector>></:vector>+ copy-on-write 模式 - 若必须原地修改，锁范围要覆盖整个读-改-写周期，不能只锁
push_back单个操作 - 警惕隐式共享：某些 STL 实现的
std::string或std::vector可能有写时复制（COW）优化，但 C++11 后标准已禁止 vector 的 COW，这点务必确认编译器版本和标准模式（-std=c++17）
最易被忽略的是：崩溃堆栈里的函数名可能是内联展开后的结果，std::vector::operator[] 下面那一层，往往藏着你亲手写的 update_cache() ——而它正用裸指针缓存了 vector 的 data() 地址。
