CODEWITHSUNDEEP
c++memory-leaksqt5valgrindqthread
closer_ex
closer_ex

Reputation: 23

Valgrind reports memory leak on QThread::start()

The issue is on VMware, somehow 3D acceleration causes memory leak and SIGSEGV, resulting in program crashing.

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

I have a problem with following codes:

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

This should be a regular sub-thread initialization, but valgrind memory analyzer says:

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

directly pointing to subthread->start(). The scene is not the parent but a QGraphicsScene pointer passed to do some computing in sub-thread, and I manually delete gc after quit()&wait() subthread in my destructor. The program runs smoothly, but I cant do any memory analyzing because of this.

There are 2 definite leaks if I check External Errors, leading to QApplication a(argc, argv); and malloc in 'vg_replace_malloc.c'.

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

Where could the leak happen?

Upvotes: 1

Views: 474

Answers (2)

Kuba hasn't forgotten Monica
Kuba hasn't forgotten Monica

Reputation: 98425

You're using the GTK+ style in your Qt application. That's clearly visible in the call stack from the crash: all those symbols that contain gtk in them are the GTK+ Qt style. This is bad news in most cases as far as profiling or memory leak testing is concerned.

Start your program like myprogram -style Fusion - that way the GTK+ style won't be used.

For example, to start it under valgrind:

valgrind myprogram -style Fusion

You don't want to be fixing GTK and Qt/GTK interop layer bugs along with your own code :)

Upvotes: 0

bruno
bruno

Reputation: 32586

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

The message is possibly lost, that means the Widget is still reachable, this is not a definitive memory leak like in int * x=new int; x = NULL;

You have that message because when your program finishes you did not deleted/freed all the allocated dynamic memory, that does not means your program is wrong.

Look at definitely lost blocks, if you do not have all is ok in fact. For that you can use the option --show-leak-kinds=definite which is equivalent to do --show-reachable=no --show-possibly-lost=no

Upvotes: 1

Related Questions