问题出在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()delete gc之后手动进行了subthread的操作。该程序运行平稳，但是由于这个原因我无法进行任何内存分析。如果我检查“外部错误”，肯定有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
泄漏在哪里发生？
最佳答案
您正在Qt应用程序中使用GTK +样式。从崩溃中的调用堆栈中可以清楚地看到这一点:所有包含gtk的符号都是GTK + Qt样式。在大多数情况下，就性能分析或内存泄漏测试而言，这是个坏消息。
像myprogram -style Fusion一样启动程序-这样就不会使用GTK+样式。
例如，要在valgrind下启动它:
valgrind myprogram -style Fusion
您不想与您自己的代码一起修复GTK和Qt / GTK互操作层错误:)
关于c++ - Valgrind报告QThread::start()上的内存泄漏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62156260/