Valgrind 在 QThread::start() 上报告内存泄漏

Question

VMware问题，不知何故3D加速导致内存泄漏和SIGSEGV，导致程序崩溃。

===============================

我对以下代码有疑问：

    gc = new GameController(scene);
    subthread = new QThread(this);
    gc->moveToThread(subthread);
    subthread->start();

这应该是一个常规的子线程初始化，但是 valgrind 内存分析器说：

416 bytes in 1 blocks are possibly lost in loss record 8,318 of 8,856
  in Widget::Widget(QWidget*) in /home/closer_ex/QtProjects/LifeGameWithTest/LifeGame/widget.cpp:15
  1: calloc in /builddir/build/BUILD/valgrind-3.15.0/coregrind/m_replacemalloc/vg_replace_malloc.c:762
  2: allocate_dtv in /usr/lib64/ld-2.28.so
  3: _dl_allocate_tls in /usr/lib64/ld-2.28.so
  4: pthread_create@@GLIBC_2.2.5 in /usr/lib64/libpthread-2.28.so
  5: QThread::start(QThread::Priority) in /home/closer_ex/Qt5.13.2/5.13.2/gcc_64/lib/libQt5Core.so.5.13.2
  6: Widget::Widget(QWidget*) in /home/closer_ex/QtProjects/LifeGameWithTest/LifeGame/widget.cpp:15
  7: main in /home/closer_ex/QtProjects/LifeGameWithTest/LifeGame/main.cpp:8

直接指向subthread->start()。 scene 不是父对象，而是传递给子线程中的一些计算的 QGraphicsScene 指针，我在析构函数中的 quit()&wait() subthread 之后手动 delete gc。程序运行很流畅，但是我无法进行任何内存分析。

如果我检查外部错误，则有 2 个明确的泄漏，导致 'vg_replace_malloc.c' 中的 QApplication a(argc, argv); 和 malloc。

544 bytes in 11 blocks are definitely lost in loss record 8,418 of 8,861
  in _dl_close_worker in /usr/lib64/ld-2.28.so
  1: malloc in /builddir/build/BUILD/valgrind-3.15.0/coregrind/m_replacemalloc/vg_replace_malloc.c:309
  2: _dl_close_worker in /usr/lib64/ld-2.28.so
  3: _dl_close in /usr/lib64/ld-2.28.so
  4: _dl_catch_exception in /usr/lib64/libc-2.28.so
  5: _dl_catch_error in /usr/lib64/libc-2.28.so
  6: _dlerror_run in /usr/lib64/libdl-2.28.so
  7: dlclose in /usr/lib64/libdl-2.28.so
  8: g_module_close in /usr/lib64/libgmodule-2.0.so.0.5600.4
  9: /usr/lib64/libgio-2.0.so.0.5600.4
  10: g_type_module_unuse in /usr/lib64/libgobject-2.0.so.0.5600.4
  11: /usr/lib64/libgio-2.0.so.0.5600.4
  12: g_io_extension_point_get_extensions in /usr/lib64/libgio-2.0.so.0.5600.4
  13: /usr/lib64/libgio-2.0.so.0.5600.4
  14: g_settings_backend_get_default in /usr/lib64/libgio-2.0.so.0.5600.4
  15: /usr/lib64/libgio-2.0.so.0.5600.4
  16: /usr/lib64/libgobject-2.0.so.0.5600.4
  17: g_object_new_valist in /usr/lib64/libgobject-2.0.so.0.5600.4
  18: g_object_new in /usr/lib64/libgobject-2.0.so.0.5600.4
  19: g_settings_new_full in /usr/lib64/libgio-2.0.so.0.5600.4
  20: /usr/lib64/libgdk-3.so.0.2200.30
  21: /usr/lib64/libgdk-3.so.0.2200.30
  22: gdk_display_manager_open_display in /usr/lib64/libgdk-3.so.0.2200.30
  23: gtk_init_check in /usr/lib64/libgtk-3.so.0.2200.30
  24: gtk_init in /usr/lib64/libgtk-3.so.0.2200.30
  25: QGtk3Theme::QGtk3Theme() in /home/closer_ex/Qt5.13.2/5.13.2/gcc_64/plugins/platformthemes/libqgtk3.so

泄漏可能发生在哪里？

Answer 1

416 bytes in 1 blocks are possibly lost in loss record 8,318 of 8,856

消息是 可能丢失，这意味着 Widget 仍然可以访问，这不是像 int * x=new int; x = NULL;

你有那个消息是因为当你的程序完成时你没有deleted/freed所有分配的动态内存，这并不意味着你的程序是错误的。

看看肯定丢块，其实你没有就万事大吉了。为此，您可以使用 --show-leak-kinds=definite 选项，它等同于 --show-reachable=no --show-possibly-lost=no

Answer 2

您正在 Qt 应用程序中使用 GTK+ 样式。这在崩溃的调用堆栈中清晰可见：所有包含 gtk 的符号都是 GTK+ Qt 样式。就分析或内存泄漏测试而言，这在大多数情况下是个坏消息。

像 myprogram -style Fusion 那样启动程序 - 这样就不会使用 GTK+ 样式。

例如在valgrind下启动：

valgrind myprogram -style Fusion

您不希望与您自己的代码一起修复 GTK 和 Qt/GTK 互操作层错误:)

Valgrind 在 QThread::start() 上报告内存泄漏

Valgrind reports memory leak on QThread::start()

c++

valgrind

memory-leaks

qthread

qt5