CODEWITHSUNDEEP
qtmemory-leaks
olpa
olpa

Reputation: 1227

Minimal Qt program makes memory leak

Here is a nearly minimal Qt program, which should release all the resources, including the memory:

#include <QApplication>
#include <QMainWindow>
#include <memory>

int main(int argc, char** argv) {
    QApplication app(argc, argv);
    std::unique_ptr<QWidget> wnd{new QWidget()};
    wnd->show();
    return app.exec();
}

However, valgrind says that:

LEAK SUMMARY:
   definitely lost: 979 bytes in 24 blocks
   indirectly lost: 7,858 bytes in 56 blocks
     possibly lost: 912 bytes in 19 blocks
   still reachable: 75,719 bytes in 1,080 blocks
                      of which reachable via heuristic:
                        newarray           : 832 bytes in 16 blocks
        suppressed: 0 bytes in 0 blocks
Rerun with --leak-check=full to see details of leaked memory

I expected to get zeros for "definitely lost" and "indirectly lost", but have got lost bytes. Why? Do I interpret valgrind output incorrectly, or should I call some additional exit function of Qt?

Upvotes: 3

Views: 628

Answers (2)

olpa
olpa

Reputation: 1227

A better reformulation of the question is: "valgrind suppress qt errors". There is a number of recipes, also here on stackoverflow, for example:

Suppression files for Qt memory leaks with Valgrind Suppression files for Qt memory leaks with Valgrind

The answer refers to this document from wxWidgets: Valgrind Suppression File Howto https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto

Upvotes: 0

Kuba hasn&#39;t forgotten Monica
Kuba hasn&#39;t forgotten Monica

Reputation: 98425

It is a mistaken assumption that "correct/proper/whatever your goodness metric is" code will leak no memory.

There are two kinds of leaked memory: startup, or one-time allocations that won't ever be repeated, and ongoing leaks from allocations that can be repeated an arbitrary and ever-increasing number of times. The latter are understandably problematic and should be fought viciously until they perish.

On the contrary, it is absolutely, no-qualms-about it wasteful to free startup memory. Every CPU cycle devoted to it wasted when the very next thing to happen is process termination where all the memory is released in the most cycle- and energy-efficient way possible. These allocations aren't leaks. They are on you to add to your memory debug tool's exception list.

The cultish freeing of every single block of memory right before process termination has a measurable impact on energy efficiency of applications that are executed multiple times in rapid succession. For common short-lived processes such as many Unix core utilities and build tools, including compilers, the frees prior to exit have wasted many railcar-loads of coal in power plants all over the world, and this trend shows no signs of slowing down.

Valgrind is a godsend. But you can't treat its output with veneration best afforded a finer deity. Don't develop software based on Valgrind's output as if it was a cargo cult. Understand what the output means, and act accordingly.

Upvotes: 2

Related Questions