Possible memory leak in QCoreApplication

ukoehler · wrote on 27 Mar 2014, 09:21

Hi folks,

when valgrinding Qt 5.2.1 applications I get warnings about possible memory leaks from QCoreApplications. I all the years I have been using Valgrind a possible memory leak always has been a real memory leak. Do I need to worry about this?

Sample application

main.pro:
@
CONFIG += qt debug
SOURCES += main.cpp
@

main.cpp:
@
#include <QCoreApplication>

int main(int argc, char **argv)
{
QCoreApplication app( argc, argv );
}
@

Valgrind output:
==5732== Memcheck, a memory error detector
==5732== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==5732== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5732== Command: ./main
==5732==
==5732==
==5732== HEAP SUMMARY:
==5732== in use at exit: 9,584 bytes in 37 blocks
==5732== total heap usage: 474 allocs, 437 frees, 37,017 bytes allocated
==5732==
==5732== LEAK SUMMARY:
==5732== definitely lost: 0 bytes in 0 blocks
==5732== indirectly lost: 0 bytes in 0 blocks
==5732== possibly lost: 2,448 bytes in 7 blocks
==5732== still reachable: 7,136 bytes in 30 blocks
==5732== suppressed: 0 bytes in 0 blocks
==5732== Rerun with --leak-check=full to see details of leaked memory
==5732==
==5732== For counts of detected and suppressed errors, rerun with: -v
==5732== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
ukoehler@linux-9lkn:~/devel/QtProblems/Valgrind_QCoreApplication> valgrind --leak-check=full ./main
==5736== Memcheck, a memory error detector
==5736== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==5736== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5736== Command: ./main
==5736==
==5736==
==5736== HEAP SUMMARY:
==5736== in use at exit: 9,584 bytes in 37 blocks
==5736== total heap usage: 474 allocs, 437 frees, 37,017 bytes allocated
==5736==
==5736== 240 bytes in 1 blocks are possibly lost in loss record 22 of 31
==5736== at 0x4C29D96: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
...
==5736== by 0x578DED4: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x578DF7F: QEventDispatcherGlib::QEventDispatcherGlib(QObject*) (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x573CB18: QCoreApplicationPrivate::createEventDispatcher() (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x5742C1C: QCoreApplication::init() (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736==
==5736== 720 bytes in 3 blocks are possibly lost in loss record 28 of 31
==5736== at 0x4C29D96: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
...
==5736== by 0x578DED4: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x578DF7F: QEventDispatcherGlib::QEventDispatcherGlib(QObject*) (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x573CB18: QCoreApplicationPrivate::createEventDispatcher() (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x5742C1C: QCoreApplication::init() (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736==
==5736== 1,488 bytes in 3 blocks are possibly lost in loss record 30 of 31
==5736== at 0x4C29D96: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
...
==5736== by 0x578DD22: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x578DF7F: QEventDispatcherGlib::QEventDispatcherGlib(QObject*) (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x573CB18: QCoreApplicationPrivate::createEventDispatcher() (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736== by 0x5742C1C: QCoreApplication::init() (in /opt/Qt/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
==5736==
==5736== LEAK SUMMARY:
==5736== definitely lost: 0 bytes in 0 blocks
==5736== indirectly lost: 0 bytes in 0 blocks
==5736== possibly lost: 2,448 bytes in 7 blocks
==5736== still reachable: 7,136 bytes in 30 blocks
==5736== suppressed: 0 bytes in 0 blocks
Any hint would be greatly appreciated. I found a bug report for definite memory loss in this case for earlier Qt versions, but could not find anything about this possible memory loss.

Many thanks in advance

Uwe

JKSH · wrote on 27 Mar 2014, 11:08

Hi,

Valgrind is known to produce lots of false positives with Qt. That's because Qt does a lot of low-level memory optimizations that a computer science lecturer might frown upon. Valgrind is just being cautious.

ukoehler · wrote on 27 Mar 2014, 12:35

Many thanks for the reply. Is there a valgrind suppression file for Qt 5.2.1 with all the messages that I do not have to worry about? Beats trying to build one myself and including problems I actually created. I found more problems in the meantime.

Cheers

Uwe

pagghiu · wrote on 27 Mar 2014, 17:26

Is this the same reason why in Visual Studio 2012 (I'm on Win7 x64) and Qt 5.2.1 x64 Angle, any QtQuick Project with CRT Leak checking enabled spits hundreds of "memory leaks" warnings?

As a test, just I've included <crtdbg.h> setting:
@
_CrtSetDbgFlag (_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
@

Project I have tested is:
_Qt\Qt5.2.1\5.2.1\msvc2012_64\examples\quick\controls\touch_

If answer is "yes they're false positive", is there any way to suppress those but still get "real" leaks, made by me?

Leak Log Results:

@Detected memory leaks!
Dumping objects ->
{167047} normal block at 0x0000000003577280, 16 bytes long.
Data: <0yW > 30 79 57 03 00 00 00 00 00 00 00 00 00 00 00 00
{167046} normal block at 0x0000000003569500, 16 bytes long.
Data: < xW > F8 78 57 03 00 00 00 00 00 00 00 00 00 00 00 00
{167045} normal block at 0x00000000035DC130, 16 bytes long.
Data: < xW > C0 78 57 03 00 00 00 00 00 00 00 00 00 00 00 00
{167044} normal block at 0x0000000003576F50, 16 bytes long.
Data: < xW > 88 78 57 03 00 00 00 00 00 00 00 00 00 00 00 00

//...LOTS OF LEAK LOG OMITTED...
//...LOTS OF LEAK LOG OMITTED...

{2270} normal block at 0x0000000000294FE0, 112 bytes long.
Data: < U > 08 00 00 00 00 00 00 00 98 E2 FB 55 00 00 00 00
{188} normal block at 0x000000000026ED90, 176 bytes long.
Data: < ? U & > D8 3F FB 55 00 00 00 00 10 ED 26 00 00 00 00 00
{187} normal block at 0x000000000026ED10, 16 bytes long.
Data: < ? U & > F8 3F FB 55 00 00 00 00 90 ED 26 00 00 00 00 00
{186} normal block at 0x000000000026E320, 112 bytes long.
Data: < U > 06 00 00 00 00 00 00 00 98 E2 FB 55 00 00 00 00
Object dump complete.
The program '[3676] touch.exe: Native' has exited with code 0 (0x0).
@

JKSH · wrote on 27 Mar 2014, 22:05

[quote author="ukoehler" date="1395923716"]Many thanks for the reply. Is there a valgrind suppression file for Qt 5.2.1 with all the messages that I do not have to worry about? Beats trying to build one myself and including problems I actually created. I found more problems in the meantime.[/quote]Hi Uwe,

I'm not aware of any existing suppression files, sorry.

[quote author="pagghiu" date="1395941201"]Is this the same reason why in Visual Studio 2012 (I'm on Win7 x64) and Qt 5.2.1 x64 Angle, any QtQuick Project with CRT Leak checking enabled spits hundreds of "memory leaks" warnings?[/quote]Hi pagghiu,

Maybe -- I have no experience with the CRT leak checker, unfortunately.

[quote author="pagghiu" date="1395941201"]If answer is "yes they're false positive", is there any way to suppress those but still get "real" leaks, made by me?[/quote]It's probably best to ask at the MSDN forums -- there should be lots of users there who know the answer.

ukoehler · wrote on 28 Mar 2014, 08:05

Hi pagghiu, hi JKSH,

many thanks for your replies. I tend to agree with pagghiu that the situation is not quite ideal. Obviously we are talking about very few bytes being leaked and no warning or errors (I have seen third party libs where valgrind stopped after listing 1 million errors and requested to come back later once programming had been learned).

The worrying thing is that I almost missed a small memory leak I introduced when building a valgrind suppression file yesterday. This makes it very difficult to use the very useful tool. I also found post in this forum showing that some of the warnings are real.

I also compile with all possible gcc warnings active and get a few warnings from Qt headers. I am very willing to help as much as I can. However, I find it difficult to find the edge between getting on the nerves of developers creating such a great tool and contributing as much as I can. Not sure where to get an answer to that question.

Cheers

Uwe

pagghiu · wrote on 28 Mar 2014, 13:43

I will head to MSDN forums, as JKSH was suggesting, they may have some answers.

Regarding ukoehler, I agree that valgrind is very useful but in my opinion we should all try to give decent separation of backend/frontend to our softwares and do some minimal unit testing or similar.
I am (pretty) sure that my pieces of software are not leaking because I can test it on a very isolated environment where I catch memory bugs before code goes to production.
And I am also confident that Qt is not leaking because after long time running, I don't see significant memory increase, maybe they're just "leak on exit" or VisualStudio CRT not understanding smart memory hacks made by the Qt team.

I will report here any discovery I will make on the topic.

Thanks everyone for answering!