c++ - 来自 tcmalloc 的意外行为

Question

我已经在一个大型项目中使用 tcmalloc 几个月了，到目前为止，我必须说我对它非常满意，最重要的是它的 HeapProfiling 功能可以跟踪内存泄漏并删除它们。

在过去的几周里，尽管我们的应用程序出现了随机崩溃，但我们找不到随机崩溃的根源。在一个非常特殊的情况下，当应用程序崩溃时，我们发现其中一个应用程序线程的堆栈完全损坏。有几次我发现线程卡在 tcmalloc::PageHeap::AllocLarge() 中，但由于我没有链接 tcmalloc 的调试符号，所以我无法理解问题所在。

经过近一周的调查，今天我尝试了最简单的事情:从链接中删除 tcmalloc 以避免使用它，只是为了看看发生了什么。好吧...我终于找到了问题所在，违规代码看起来非常像这样:

   void AllocatingFunction()
   {
       Object object_on_stack;
       ProcessObject(&object_on_stack);

   }

   void ProcessObject(Object* object)
   {
       ...
       // Do Whatever
       ...
       delete object;
   }

使用 libc 应用程序仍然崩溃，但我终于看到我正在对分配在堆栈上的对象调用 delete。

我仍然不明白的是，为什么 tcmalloc 反而让应用程序保持运行，而不管这个非常危险的(如果不是完全错误的)对象释放，以及当 AllocatingFunction 结束时 object_on_stack 超出范围时的双重释放。事实上，有问题的代码可能会被重复调用而没有任何潜在可憎的暗示。

我知道如果使用不当，内存释放是那些“未定义行为”之一，但令我惊讶的是“标准”libc 和 tcmalloc 之间的行为如此不同。

有没有人对为什么 tcmalloc 保持应用程序运行有某种洞察力的解释？

提前致谢:)

祝你有个愉快的一天

Answer 1

very risky (if not utterly wrong) object deallocation

好吧，我在这里不同意，它是完全错误的，并且由于您调用 UB，任何事情都可能发生。

这在很大程度上取决于 tcmalloc 代码在解除分配时实际执行的操作，以及它如何使用该位置堆栈周围的(可能是垃圾)数据。

我也见过 tcmalloc 在这种情况下崩溃，以及 glibc 进入无限循环。您所看到的只是巧合。