valgrind 能报出构造函数中分配但未释放的内存，但不指出语义问题；它仅追踪 operator new/malloc 调用，若构造函数中 new 未配对 delete 且对象生命周期长，退出时即报 definitely lost。
构造函数里分配的内存，Valgrind 能不能报出来
能，但只报“谁分配了没还”，不报“因为构造函数没写好”。Valgrind 不解析 C++ 语义，它只盯 operator new、malloc 这些调用点。只要构造函数里调了 new 却没对应 delete（或没被 RAII 封装），且对象生命周期足够长（比如全局/静态/堆上对象），退出时就会被归为 definitely lost。
常见漏点：
- 在构造函数里用
new int[100]初始化成员指针，但析构函数空着或没写delete[] - 构造函数抛异常前已分配内存，但没用
try/catch或 RAII 清理，导致operator new分配了却没走到析构 - 用了
placement new：Valgrind 完全不跟踪，也不会报泄漏——它只管堆内存
析构函数没释放，Valgrind 怎么定位到是析构的问题
Valgrind 不会说“析构函数漏写了”，但它会把泄漏源头指向 operator new 的调用栈，而这个调用栈往往就停在构造函数里。关键看报告里的 at 0x...: Base::Base(int) (base.cpp:12) 这一行——很多人直接跳过，其实这就是线索。
实操要点：
- 编译必须带
-g -O0，否则堆栈里只有地址，看不到Base::Base - 加
--leak-check=full --show-leak-kinds=all，确保报告包含完整调用链 - 如果泄漏块的
by 0x...指向operator new，再往上翻两层，大概率就是构造函数某行 - 对比源码：确认那行是不是
a = new int(...)类型的裸分配，且类里没有对应的delete逻辑
为什么有时候 Valgrind 报告里根本没提构造函数名
不是 Valgrind 隐藏了，是你编译或运行环境屏蔽了关键信息。
典型原因：
- 编译没加
-g：符号表缺失，报告里只有???或十六进制地址 - 开了
-O2或更高优化：构造函数被内联，调用栈直接跳到main或operator new，中间层消失 - 用了模板或 std::make_shared：实际分配发生在底层库函数里，堆栈可能显示
std::allocator::allocate而非你的构造函数 - 对象是栈上创建又立即销毁的：内存刚分配就释放，Valgrind 压根不会记为泄漏
查构造/析构泄漏最有效的命令组合
别用默认参数跑，容易错过关键线索。
推荐命令：
valgrind --tool=memcheck \ --leak-check=full \ --show-leak-kinds=all \ --track-origins=yes \ --verbose \ --log-file=valgrind.log \ ./your_program
重点参数作用：
-
--leak-check=full：不只报“有泄漏”，还列出每一块的分配点 -
--show-leak-kinds=all：区分definitely lost、possibly lost，前者基本就是构造分配 + 析构没清 -
--track-origins=yes：对未初始化读这类问题极有用，顺带让构造函数内的初始化逻辑更透明 -
--verbose：看到 Valgrind 加载了哪些符号、是否识别出你的源文件路径
真正容易被忽略的是报告末尾的 HEAP SUMMARY 和每一处 definitely lost 后面跟着的完整调用栈——它不会主动告诉你“去检查析构函数”，但只要你顺着栈往回看两层，几乎总能落到构造函数那一行。
