销毁weak_ptr时崩溃：shared_ptr_emplace对象重复释放问题求助

API 探路者

2026-5-15

排查weak_ptr析构时偶发malloc崩溃问题

从你给出的崩溃日志、代码场景和对象生命周期描述来看，这个偶发的weak_ptr析构崩溃，核心问题大概率出在异步场景下的竞态条件或者对象控制块的生命周期管理漏洞上。下面是一步步的排查思路和可能的修复方向：

1. 先揪出控制块重复释放的根源

崩溃日志里的pointer being freed was not allocated，结合weak_ptr的析构逻辑（调用__release_weak()后释放控制块），最可疑的是：

当回调里的pTransfer销毁时，CancelableToken的最后一个shared_ptr被释放，此时控制块的强引用计数归零，会销毁CancelableToken对象，同时检查弱引用计数——正常情况下，你的ControlSend栈里还有token这个weak_ptr，弱引用计数应该大于0，控制块不该被释放。
那为什么会触发重复释放？你要检查这几个点：
- 确认SendControlBytesVendorAsync返回的weak_ptr是否正确关联到CancelableToken的控制块：有没有可能在某些边界场景下，这个weak_ptr被错误初始化（比如对象还没被shared_ptr持有就调用了weak_from_this()，导致返回空或者无效的weak_ptr）？
- 检查CancelableToken继承enable_shared_from_this的使用是否规范：必须确保对象被shared_ptr持有后，再调用weak_from_this()获取弱引用，否则会导致控制块关联异常。

你的ControlSend是阻塞等待future，而回调在异步线程执行，这里很容易出现隐性竞态：

比如当fut.wait_for刚超时，主线程执行LOCK_AND_CANCEL(token)的同时，异步回调刚好完成，正在销毁pTransfer进而释放CancelableToken的shared_ptr。两个线程同时操作同一个控制块，就可能导致弱引用计数被错误修改，最终触发重复释放。
修复建议：给CancelableToken的控制块操作（包括__release_weak()、取消方法等）加上线程安全保护，比如用一个互斥锁包裹控制块的计数修改逻辑。另外，在LOCK_AND_CANCEL里，一定要先通过token.lock()获取shared_ptr，确认对象还活着再执行取消操作：
```
if (auto shared_token = token.lock()) {
    // 执行取消逻辑
    shared_token->Cancel();
}
```
避免直接用weak_ptr访问已销毁的对象。

偶发的malloc错误经常和堆内存破坏有关，比如：

AUsbTransfer或CancelableToken内部存在越界写、野指针访问等问题，破坏了weak_ptr控制块（__cntrl_指向的内存）。
可以用工具快速定位：
- macOS/Xcode环境：开启Zombie Objects和Malloc Guard Edges，或者用malloc_history追踪崩溃地址的分配/释放记录；
- Linux环境：用valgrind的memcheck工具检测内存越界。
另外，你当前打印的&token是weak_ptr对象本身的地址，建议改成打印token.__cntrl_的地址（如果能访问内部成员的话），对比崩溃时的地址，确认是不是同一个控制块被多次释放。

ControlSend里的token是栈上的weak_ptr，函数退出时自动析构。你可以在函数退出前加个检查，确认weak_ptr的状态：

DEBUG_PRINT("Token expired? %d", token.expired());
DEBUG_PRINT("Control block address: %p", token.__cntrl_);

如果expired()返回true，但析构时还是崩溃，说明控制块已经被释放，但__cntrl_指针没有被正确置空，这就是典型的生命周期管理漏洞。

这个宏是超时场景的关键操作，很可能藏着问题：

内容的提问来源于stack exchange，提问作者Kartik Aiyer