Re: Memory leaks in QT apps
What about the details of the leaks? Run valgrind with --show-reachable=yes and --leak-check=full
Re: Memory leaks in QT apps
Hi,
the following is the output:
==6834== 92,301 bytes in 1,872 blocks are still reachable in loss record 134 of 134
==6834== at 0x4021259: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==6834== by 0x493CF4A: FcPatternGet (in /usr/lib/libfontconfig.so.1.0.4)
==6834== by 0x493D1D1: FcPatternGetString (in /usr/lib/libfontconfig.so.1.0.4)
==6834== by 0x492A89F: FcConfigBuildFonts (in /usr/lib/libfontconfig.so.1.0.4)
==6834== by 0x49336FE: FcInitLoadConfigAndFonts (in /usr/lib/libfontconfig.so.1.0.4)
==6834== by 0x4933804: FcInit (in /usr/lib/libfontconfig.so.1.0.4)
==6834== by 0x4190D8A: ??? (qapplication_x11.cpp:1358)
==6834== by 0x4138998: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (qapplication.cpp:709)
==6834== by 0x4139782: QApplication::QApplication(int&, char**, int) (qapplication.cpp:619)
==6834== by 0x804AD4C: main (main.cpp:8)
.
like this it shows for all the blocks.
saravanan
Re: Memory leaks in QT apps
This one is not a leak per se.
It is a globally acquired resorce that does not get freed.
It does not have to be freed, as -when the program terminates- it is freed automatically.
Therefore it is a bit more efficient not to free it explicitly. Causes you a bit of pain when debugging with valgrind.
As a rule of thumb, Qt itself is generally free of memleaks as the Trollies use valgrind extensively.
Unless the leaks accumulate it is usually best to ignore Qt/X11 'leaks' and concentrate on your own. valgrind tells you (backtrace) if the leak is one of yours.
HTH
Re: Memory leaks in QT apps
hi ,
So should i consider these memory leaks or shall i skip ..?
saravanan
Re: Memory leaks in QT apps
What you posted is just one 'leak'.
Ignore it. (If it was a leak it would be an issue of Qt / fontconfig).
Re: Memory leaks in QT apps
Hi,
I have been using Qt recently, and I have similar doubts and decided to post here since someone has already started a thread recently. I am not gonna talk about my project, since it has issues of its own, but while checking it for memory leaks I believe I found some Qt leaks too.
So I ran memcheck on the simplest exaple program of the tutorial - the 'hello' button. I didn't bother about the reachable blocks, and here is the report:
Quote:
==5482== Memcheck, a memory error detector.
==5482== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5482== Using LibVEX rev 1658, a library for dynamic binary translation.
==5482== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5482== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==5482== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5482== For more details, rerun with: -v
==5482==
==5482==
==5482== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 58 from 3)
==5482== malloc/free: in use at exit: 78,797 bytes in 2,790 blocks.
==5482== malloc/free: 18,700 allocs, 15,910 frees, 6,996,972 bytes allocated.
==5482== For counts of detected errors, rerun with: -v
==5482== searching for pointers to 2,790 not-freed blocks.
==5482== checked 513,500 bytes.
==5482==
==5482== 20 bytes in 1 blocks are definitely lost in loss record 18 of 86
==5482== at 0x4005400: malloc (vg_replace_malloc.c:149)
==5482== by 0x4F3EDD0F: strdup (in /lib/libc-2.5.so)
==5482== by 0x419A66E: qt_init(QApplicationPrivate*, int, _XDisplay*, unsigned long, unsigned long) (qapplication_x11.cpp:2213)
==5482== by 0x4136818: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (qapplication.cpp:740)
==5482== by 0x4137602: QApplication::QApplication(int&, char**, int) (qapplication.cpp:672)
==5482== by 0x8048793: main (main.cpp:12)
==5482==
==5482==
==5482== 56 bytes in 1 blocks are definitely lost in loss record 33 of 86
==5482== at 0x4005400: malloc (vg_replace_malloc.c:149)
==5482== by 0x4F72A9FF: (within /usr/lib/libXcursor.so.1.0.2)
==5482== by 0x4F72B205: (within /usr/lib/libXcursor.so.1.0.2)
==5482== by 0x4F72BC51: XcursorXcFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==5482== by 0x4F72BD6A: XcursorFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==5482== by 0x4F72C660: XcursorLibraryLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==5482== by 0x4F72C854: XcursorLibraryLoadCursor (in /usr/lib/libXcursor.so.1.0.2)
==5482== by 0x41A1740: QCursorData::update() (qcursor_x11.cpp:290)
==5482== by 0x41A1CB5: QCursor::handle() const (qcursor_x11.cpp:139)
==5482== by 0x41AED8D: qt_x11_enforce_cursor(QWidget*, bool) (qwidget_x11.cpp:313)
==5482== by 0x41AEE28: qt_x11_enforce_cursor(QWidget*) (qwidget_x11.cpp:326)
==5482== by 0x41B39C7: QWidgetPrivate::create_sys(unsigned long, bool, bool) (qwidget_x11.cpp:766)
==5482==
==5482==
==5482== 214 bytes in 9 blocks are definitely lost in loss record 50 of 86
==5482== at 0x4005400: malloc (vg_replace_malloc.c:149)
==5482== by 0x4F6DF527: FcStrCopy (in /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F6E2C06: (within /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F629215: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F629E8C: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F62AE8D: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F62BDD4: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F6235CA: XML_ParseBuffer (in /lib/libexpat.so.0.5.0)
==5482== by 0x4F6E1D7B: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F6E2082: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F6E24F7: (within /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F629215: (within /lib/libexpat.so.0.5.0)
==5482==
==5482==
==5482== 744 bytes in 3 blocks are possibly lost in loss record 66 of 86
==5482== at 0x4004600: memalign (vg_replace_malloc.c:332)
==5482== by 0x400465A: posix_memalign (vg_replace_malloc.c:421)
==5482== by 0xBC2DC8: (within /lib/libglib-2.0.so.0.1200.9)
==5482== by 0xBC382B: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.9)
==5482== by 0xB8EBF8: g_array_sized_new (in /lib/libglib-2.0.so.0.1200.9)
==5482== by 0xB8ED06: g_array_new (in /lib/libglib-2.0.so.0.1200.9)
==5482== by 0xBCAC72: g_static_private_set (in /lib/libglib-2.0.so.0.1200.9)
==5482== by 0xB96B1B: g_get_filename_charsets (in /lib/libglib-2.0.so.0.1200.9)
==5482== by 0xB96B90: (within /lib/libglib-2.0.so.0.1200.9)
==5482== by 0xBCAD49: g_thread_init_glib (in /lib/libglib-2.0.so.0.1200.9)
==5482== by 0x38D579: g_thread_init (in /lib/libgthread-2.0.so.0.1200.9)
==5482== by 0x4A491FB: QEventDispatcherGlibPrivate::QEventDispatcherGlibP rivate(_GMainContext*) (qeventdispatcher_glib.cpp:230)
==5482==
==5482==
==5482== 1,332 (1,152 direct, 180 indirect) bytes in 9 blocks are definitely lost in loss record 70 of 86
==5482== at 0x4005400: malloc (vg_replace_malloc.c:149)
==5482== by 0x4F6DCED3: (within /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F6DD7E3: (within /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F6DD8E6: (within /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F6E2A80: (within /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F629215: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F629E8C: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F62AE8D: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F62BDD4: (within /lib/libexpat.so.0.5.0)
==5482== by 0x4F6235CA: XML_ParseBuffer (in /lib/libexpat.so.0.5.0)
==5482== by 0x4F6E1D7B: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.1.0)
==5482== by 0x4F6E2082: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.1.0)
==5482==
==5482== LEAK SUMMARY:
==5482== definitely lost: 1,442 bytes in 20 blocks.
==5482== indirectly lost: 180 bytes in 9 blocks.
==5482== possibly lost: 744 bytes in 3 blocks.
==5482== still reachable: 76,431 bytes in 2,758 blocks.
==5482== suppressed: 0 bytes in 0 blocks.
==5482== Reachable blocks (those to which a pointer was found) are not shown.
==5482== To see them, rerun with: --show-reachable=yes
Does anyone know whether those are indeed leaks, or Valgrind is just not referencing stuff too well? I know that Trolltech use memory checking.
Edit: Of all those leaks, only the first one might be caused by Qt. The rest might be leaks from X or thegnome library. I am not too sure though.
Re: Memory leaks in QT apps
