Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. valgrind reports memory still reachable, allocated by libglib
Forum Updated to NodeBB v4.3 + New Features

valgrind reports memory still reachable, allocated by libglib

Scheduled Pinned Locked Moved Solved General and Desktop
3 Posts 3 Posters 531 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    sdhiker
    wrote on last edited by
    #1

    Does this valgrind report present a possible memory leak and is there anything that can be done to get valgrind to instead report that all heap blocks are freed?

    main.cpp:

    #include <QTemporaryDir>
    
    int main() {
        QTemporaryDir d;
    }
    

    Build steps:

    /usr/bin/c++ -fPIC -DQT_DISABLE_DEPRECATED_BEFORE=0x050F00 -g -std=gnu++17 -isystem /home/sdhiker/Qt/6.2.0/gcc_64/include/QtCore -isystem /home/sdhiker/Qt/6.2.0/gcc_64/include -isystem /home/sdhiker/Qt/6.2.0/gcc_64/mkspecs/linux-g++ -o main.o -c main.cpp
    /usr/bin/c++ -g main.o -Wl,-rpath,/home/sdhiker/Qt/6.2.0/gcc_64/lib /home/sdhiker/Qt/6.2.0/gcc_64/lib/libQt6Core.so.6.2.0
    

    Program execution and valgrind report:

    λ valgrind --leak-check=full --show-leak-kinds=all ./a.out
    ==22265== Memcheck, a memory error detector
    ==22265== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==22265== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
    ==22265== Command: ./a.out
    ==22265== 
    ==22265== 
    ==22265== HEAP SUMMARY:
    ==22265==     in use at exit: 18,612 bytes in 6 blocks
    ==22265==   total heap usage: 63 allocs, 57 frees, 135,817 bytes allocated
    ==22265== 
    ==22265== 4 bytes in 1 blocks are still reachable in loss record 1 of 6
    ==22265==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==22265==    by 0x73588E3: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x7358F03: g_private_get (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x732A460: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x72F92E1: g_hash_table_new_full (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x731C7C2: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x4011B89: call_init.part.0 (dl-init.c:72)
    ==22265==    by 0x4011C90: call_init (dl-init.c:30)
    ==22265==    by 0x4011C90: _dl_init (dl-init.c:119)
    ==22265==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
    ==22265== 
    ==22265== 32 bytes in 1 blocks are still reachable in loss record 2 of 6
    ==22265==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==22265==    by 0x7311EF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x72F802F: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x72F9320: g_hash_table_new_full (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x731C7C2: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x4011B89: call_init.part.0 (dl-init.c:72)
    ==22265==    by 0x4011C90: call_init (dl-init.c:30)
    ==22265==    by 0x4011C90: _dl_init (dl-init.c:119)
    ==22265==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
    ==22265== 
    ==22265== 64 bytes in 1 blocks are still reachable in loss record 3 of 6
    ==22265==    at 0x483B723: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==22265==    by 0x483E017: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==22265==    by 0x7311F3F: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x72F801A: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x72F9320: g_hash_table_new_full (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x731C7C2: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x4011B89: call_init.part.0 (dl-init.c:72)
    ==22265==    by 0x4011C90: call_init (dl-init.c:30)
    ==22265==    by 0x4011C90: _dl_init (dl-init.c:119)
    ==22265==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
    ==22265== 
    ==22265== 96 bytes in 1 blocks are still reachable in loss record 4 of 6
    ==22265==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==22265==    by 0x7311E98: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x732A485: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x72F92E1: g_hash_table_new_full (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x731C7C2: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x4011B89: call_init.part.0 (dl-init.c:72)
    ==22265==    by 0x4011C90: call_init (dl-init.c:30)
    ==22265==    by 0x4011C90: _dl_init (dl-init.c:119)
    ==22265==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
    ==22265== 
    ==22265== 2,032 bytes in 1 blocks are still reachable in loss record 5 of 6
    ==22265==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==22265==    by 0x7311EF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x7335B65: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x732A6D2: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x72F92E1: g_hash_table_new_full (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x731C7C2: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x4011B89: call_init.part.0 (dl-init.c:72)
    ==22265==    by 0x4011C90: call_init (dl-init.c:30)
    ==22265==    by 0x4011C90: _dl_init (dl-init.c:119)
    ==22265==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
    ==22265== 
    ==22265== 16,384 bytes in 1 blocks are still reachable in loss record 6 of 6
    ==22265==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==22265==    by 0x7311E98: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x731C7D3: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
    ==22265==    by 0x4011B89: call_init.part.0 (dl-init.c:72)
    ==22265==    by 0x4011C90: call_init (dl-init.c:30)
    ==22265==    by 0x4011C90: _dl_init (dl-init.c:119)
    ==22265==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
    ==22265== 
    ==22265== LEAK SUMMARY:
    ==22265==    definitely lost: 0 bytes in 0 blocks
    ==22265==    indirectly lost: 0 bytes in 0 blocks
    ==22265==      possibly lost: 0 bytes in 0 blocks
    ==22265==    still reachable: 18,612 bytes in 6 blocks
    ==22265==         suppressed: 0 bytes in 0 blocks
    ==22265== 
    ==22265== For lists of detected and suppressed errors, rerun with: -s
    ==22265== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    
    1 Reply Last reply
    0
    • Christian EhrlicherC Online
      Christian EhrlicherC Online
      Christian Ehrlicher
      Lifetime Qt Champion
      wrote on last edited by
      #3

      Don't see anything Qt can do against this. Also not a "memleak" which you should take care of. Looks like some init stuff for glib. You should ask the glib developers if you want to get it fixed.

      Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
      Visit the Qt Academy at https://academy.qt.io/catalog

      1 Reply Last reply
      1
      • Kent-DorfmanK Offline
        Kent-DorfmanK Offline
        Kent-Dorfman
        wrote on last edited by
        #2

        what does "still reachable mean?" If I had to guess, I would think it means that nothing in the heap manager has invalidated the content of those blocks following deltion...as I would expect upon program exit.

        Deletion simply marks the blocks as reusable. It doesn't overwrite the data in them.

        1 Reply Last reply
        1
        • Christian EhrlicherC Online
          Christian EhrlicherC Online
          Christian Ehrlicher
          Lifetime Qt Champion
          wrote on last edited by
          #3

          Don't see anything Qt can do against this. Also not a "memleak" which you should take care of. Looks like some init stuff for glib. You should ask the glib developers if you want to get it fixed.

          Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
          Visit the Qt Academy at https://academy.qt.io/catalog

          1 Reply Last reply
          1

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved