如何针对特定情况调试和修复此双重可用内存损坏问题答案

【问题标题】：How to debug and fix this double free memory corruption issue for specific case如何针对特定情况调试和修复此双重可用内存损坏问题
【发布时间】：2018-11-02 04:28:05
【问题描述】：

当我退出该工具时，我有一个基于 QT 的 GUI，我收到以下问题

*** glibc detected *** /bin/linux_x86_64/main-g: double free or corruption 
(!prev): 0x00000000049eca50 ***
  ======= Backtrace: =========
   /lib64/libc.so.6[0x3feee75e66]
   /lib64/libc.so.6[0x3feee789b3]
    /linux_x86_64/main2- 
   g(_ZN9__gnu_cxx13new_allocatorIPN3zi_14PCommandEE10deallocateEPS3_m+0x20) 
  [0x1d9f504]
 gui//../bin/linux_x86_64/main2-g 

  _ZNSt16allocator_traitsISaIPN3zi_14PCommandEEE10deallocateERS3_PS2_m+0x2b) 
  [0x1d9f0de]
 /gui//../bin/linux_x86_64/main2-g   
(_ZNSt12_Vector_baseIPN3zi_14PCommandESaIS2_EE13_M_deallocateEPS2_m+0x32) 
[0x1d9eba6]
/gui//../bin/linux_x86_64/main2- 
 g(_ZNSt12_Vector_baseIPN3zi_14PCommandESaIS2_EED2Ev+0x41)[0x1d9e955]
../bin/linux_x86_64/main2-g(_ZNSt6vectorIPN3zi_14PCommandESaIS2_EED1Ev+0x41) 
 [0x1dc771b]
/lib64/libc.so.6(__cxa_finalize+0x9d)[0x3feee35ebd]
 ../lib/linux_x86_64/lib-g.so(+0x3a627c6)[0x7f63
 ====== Memory map: ========
 00400000-02b5f000 r-xp 00000000 08:03 21767481                           
   ../main2-g
 02d5e000-02f8c000 rw-p 0275e000 08:03 21767481                           
../main2-g
  02f8c000-03222000 rw-p 00000000 00:00 0 
03cc7000-04cac000 rw-p 00000000 00:00 0

我需要一些输入来调试这个问题。我也无法使用 Valgrind 。在这种情况下它崩溃了

【问题讨论】：

更多信息通常有助于解答。
如果我得到这样的错误，他们会让我怀疑 C++ 是否真的是一个不错的选择。错误的代码可能已经执行得更早了。内存损坏一次发生（例如，通过越界访问），但不需要立即导致崩溃。相反，一些不相关的东西被覆盖，例如一个指针。现在，这开始了一场雪崩，最后很难猜测它是从哪里开始的。恐怕 Valgrind 确实是您发现这一点的最佳选择（因为它可以识别原始的越界访问）。否则，您可能会使用“古老”的技术：分而治之。
...即分离应用程序的部分并隔离测试它们。（顺便说一句。因为我使用了智能指针，它变得好多了——不再对 C++ 有太多的怀疑了......）;-)

标签： c++ memory memory-management memory-leaks

【解决方案1】：

您的删除或免费调用之一是在已释放的内存上完成的。仔细检查所有手动内存释放并检查它们是否正确（删除可疑的并查看它是否会改变行为）。

理想情况下，使用现代 C++，您应该很少或不需要显式的 new 和 delete（使用 std 提供的智能指针）。

关于 Qt，请注意 Qt 使用父子所有权。您应该只删除“顶级”对象（没有设置“父”的对象），Qt 将自行删除已删除对象的所有子对象。即，如果您手动分配了一个 QObject 派生实例并以某种方式将其链接到 QObject 层次结构中（添加子/设置父/等），则直接删除该对象会导致麻烦。

【讨论】：