在过去的几个月中,我一直在忙着调试在一个非常大的专有C++图像处理库中的某处发生的罕见崩溃,该库使用针对ARM Cortex-A9 Linux目标的GCC 4.7.2进行编译。由于一个常见的症状是glibc抱怨堆腐败,第一步是使用堆腐败检查器来捕获oob内存写入。我使用https://stackoverflow.com/a/17850402/3779334中描述的技术将所有调用free/malloc转移到我自己的函数中,使用一定数量的已知数据填充每个已分配的内存块来捕获越界写入 - 但是什么都没找到,即使使用as在每个分配的块之前和之后大约为1 KB(由于大量使用STL容器,因此分配了数十万个块,因此我无法进一步扩大填充范围,再加上我认为任何写入超出1KB的块都会超出范围无论如何最终会触发段错误)。这个界限检查器在过去发现了其他问题,所以我不怀疑它的功能。什么可能会导致互斥错误?
(有人说“Valgrind的”之前,是的,我已经试过太没有结果无论是。)
现在,我的内存边界检查还有一个特点,它预先考虑与数据结构每一个分配的块。这些结构都链接在一个长链表中,以便我偶尔遍历所有分配和测试内存完整性。由于某些原因,即使此列表的所有操作都受到互斥锁保护,列表也会被破坏。在调查这个问题时,似乎互斥体本身偶尔无法完成其工作。这里是伪代码:
pthread_mutex_t alloc_mutex;
static bool boolmutex; // set to false during init. volatile has no effect.
void malloc_wrapper() {
// ...
pthread_mutex_lock(&alloc_mutex);
if (boolmutex) {
printf("mutex misbehaving\n");
__THROW_ERROR__; // this happens!
}
boolmutex = true;
// manipulate linked list here
boolmutex = false;
pthread_mutex_unlock(&alloc_mutex);
// ...
}
代码评论“发生这种情况!”偶尔会达到,尽管这似乎是不可能的。我的第一个理论是互斥数据结构被覆盖。我把互斥体放在一个结构体中,在它之前和之后有大的数组,但是当这个问题发生时,数组没有任何变化,所以似乎没有任何东西被覆盖。
那么..什么样的腐败可能会导致这种情况发生,我如何找到并解决问题的原因?
还有一些笔记。测试程序使用3-4个线程进行处理。使用较少的线程运行似乎使腐败不那么常见,但不会消失。测试每次运行约20秒,并在绝大多数情况下成功完成(我可以有10个单元重复测试,第一次故障发生在5分钟到几个小时后)。当问题发生时,测试时间很晚(比如15秒),所以这不是一个不好的初始化问题。内存边界检查器从来没有捕获到实际的越界写入,但glibc仍然偶尔会因损坏的堆错误而失败(这种错误是否可以由oob写入以外的其他情况引起?)。每次失败都会生成一个包含大量跟踪信息的核心转储;在这些转储中我没有看到任何模式,没有显示比其他代码更多的特定代码段。这个问题似乎非常特定于一个特定的算法家族,并且在其他算法中不会发生,所以我很确定这不是一个零星的硬件或内存错误。我已经做了很多更多的测试来检查oob堆的访问,我不想列出这些文件来阻止这篇文章再次发布。
在此先感谢您的帮助!
似乎极不可能我们可以帮你在这里。在这种情况下,你似乎完成了你应该做的大部分工作,除了把它缩小到一个更小的程序。而且,是的,我知道在这种情况下这很困难且耗时。但是,不,这不会让它变得更不重要。祝你好运! –
可能想使用此代码尝试Vagrind,并查看它是否显示任何相关的内容 –
您可以在平台上使用gcc 4.8并尝试使用AddressSanitizer(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer)吗?阅读https://en.wikipedia.org/wiki/AddressSanitizer。 –