Memory Leak On Empty Qt Widgets Application

[Alien]

Hi,
I've created an empty Qt widget application and I try to check it with Valgrind when I use :
Analyze>Valgrind Memory Analyzer
the out put was nothing and it seems all of the thing went right but when I use:
Analyze>Valgrind Memory Analyzer With GDB
the out put was:

==5361== Memcheck, a memory error detector
==5361== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5361== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==5361== Command: /home/av/build-memAnalys-Desktop_Qt_5_9_1_GCC_64bit-Debug/memAnalys
==5361== 
==5361== (action at startup) vgdb me ... 
==5361== 
==5361== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==5361==   /path/to/gdb /home/av/build-memAnalys-Desktop_Qt_5_9_1_GCC_64bit-Debug/memAnalys
==5361== and then give GDB the following command
==5361==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=5361
==5361== --pid is optional if only one valgrind process is running
==5361== 
==5361== 
==5361== HEAP SUMMARY:
==5361==     in use at exit: 1,480,519 bytes in 18,781 blocks
==5361==   total heap usage: 124,426 allocs, 105,645 frees, 13,821,454 bytes allocated
==5361== 
==5361== LEAK SUMMARY:
==5361==    definitely lost: 644 bytes in 4 blocks
==5361==    indirectly lost: 6,599 bytes in 40 blocks
==5361==      possibly lost: 3,856 bytes in 33 blocks
==5361==    still reachable: 1,386,804 bytes in 18,028 blocks
==5361==                       of which reachable via heuristic:
==5361==                         length64           : 5,336 bytes in 89 blocks
==5361==                         newarray           : 2,160 bytes in 55 blocks
==5361==         suppressed: 0 bytes in 0 blocks
==5361== Rerun with --leak-check=full to see details of leaked memory
==5361== 
==5361== For counts of detected and suppressed errors, rerun with: -v
==5361== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

As you can see it complains about memory leak why?and how to solve it?
Is it a kind of bug in Qt?

Extra information:
OS:Ubuntu 16.04 x64
Valgrind: 3.11.0
Qt:5.9.1 x64

[jsulm]

@Alien From what you posted it is unclear what is actually leaking. Why do you think it is Qt? You should check what exactly is causing it. But I doubt there is any leak - Valgrind can produce many false positives, see http://doc.qt.io/qtcreator/creator-analyzer.html

[ambershark]

@Alien Since it's just a small/empty example app, share the code here and anything causing a memory leak should be obvious.

Also according to your valgrind report I'm not seeing any real leaks, except possibly 644 bytes in 4 blocks.

The rest of it I don't think you're actually losing. And this says there's nothing erroring:
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Edit: I wrote a quick test and it showed similar results to yours, dug into it and didn't find any leaks in Qt. I did find a suspicious potential leak inside xcb/xlib though. But it was tiny so I wouldn't be concerned with it. Things look good to me. No reason to share your code. :)

[Alien]

Dear @jsulm and @ambershark :

mainwindow.h

#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QMainWindow>

namespace Ui {
class MainWindow;
}

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    explicit MainWindow(QWidget *parent = 0);
    ~MainWindow();

private:
    Ui::MainWindow *ui;
};

#endif // MAINWINDOW_H

mainwindow.cpp

#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

MainWindow::~MainWindow()
{
    delete ui;
}

main.cpp

#include "mainwindow.h"
#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.show();

    return a.exec();
}

[jsulm]

@Alien As I said I don't think there is any real memory leak. Valgrind can produce false positives especially with Qt programs. You need at least check where those alleged leaks actually are.

[Alien]

Also I try to rerun memory check with --leak-check=full --show-leak-kinds=all and here is the report:

https://www.dropbox.com/s/c30rg750og8357t/Valgrind_report?dl=0

the limitation of 32767 characters per post make me to upload a text file for you on Dropbox.

[Alien]

@jsulm I got your point but what should I do if there is any real leakage or something else in my app?how to recognize what kind of Valgrind report sentences are true and what kind are not?

could you please share your experience for checking application, I really appreciate it.

[Asperamanca]

First, what exactly are you trying to test? You open and close a window. To do so, you create a whole application then terminate it. If creating and terminating the application causes any leaks, they don't need to bother you - under normal circumstances, an OS like Linux (or Windows) will clean up any leftover allocated memory when the process ends.
More interesting is a test case that can occur multiple times while your application runs - e.g. the user opens and closes a window. If your application is supposed to run for a long time, and the tested operation may occur very often, a leak may be relevant.
I have found that, with large applications building on dozens of 3rd party libraries, trying to achieve zero memory leaks is a fool's errand. The trick is to find and eliminate those leaks that may really cause you grief, either because the leak is big, or the operation is performed very often (e.g. in a fast timer).
Of course, it depends on your circumstances - is your application going to run on a PC with tons of memory, or on an embedded device with very limited resources? Do you have a typical user application that will run for a few hours, maybe a few days before it is closed anyway, or a server application that potentially has to run for months or even years?

In all leaks marked as "definite", Qt calls other libraries. It may well be that the leak (if a leak it is) is outside of Qt's control.

[Alien]

@Asperamanca thanks for your reply I just open a window and then close it on a PC.
By the way when I close my application I usually try to free past allocated memory in some destructor is it right?It may leakage happen on closing time am I right?
Of course I did not use any 3'rd party libraries in an empty qt widget app so I expect that Valgrind did not show any leakage.

[jsulm]

@Alien Sure, you should free the memory you allocated.
"so I expect that Valgrind did not show any leakage" - as I said already, Valgrind can produce false positives. That means if Valgrind says there is a leak it can be wrong. This is even mentioned in Qt documentation: http://doc.qt.io/qtcreator/creator-analyzer.html ("Suppressing Errors").

[Asperamanca]

It is always good practice to release any memory you have allocated previously, and a class destructor is usually a good place to free memory that has been allocated for that class.

I guess in your case, valgrind observes the whole lifetime of your application, from creation to termination, and reports any portions of memory that have not been freed. Reported memory leaks for this "cradle to grave" situation need to be taken with a grain of salt: There are sometimes good reasons not to free up memory explicitly, but let the OS do it. One example are static variables, where the order of termination might hurt cleanup.

You are using Qt, which is a 3rd party library (meaning you haven't written it). And looking at the callstacks from valgrind, you can see lots of other libraries being called.

[ambershark]

@Alien said in Memory Leak On Empty Qt Widgets Application:

@jsulm I got your point but what should I do if there is any real leakage or something else in my app?how to recognize what kind of Valgrind report sentences are true and what kind are not?

could you please share your experience for checking application, I really appreciate it.

When I use valgrind to check for memory you just really need to look at that first line in the summary that says "definitely lost". If it's at all large then you probably have a real memory leak.

Memory leaks aren't an issue if they only happen at exit. As @Asperamanca said the OS will clean them up for you. It's still good practice to make sure you clean up all your memory but if some slips by only at exit, it's not that big of a deal.

Memory leaks that happen while running the app are the real problem. If you are for instance creating a buffer to hold data and forgetting to clean that buffer, and your function gets called 1000s of times, then you have a real issue where your app will destroy system resources the longer it runs. Those ones you need to catch. To do that just look at the summary I told you about and use the full report to find out what is leaking and why.

When I grabbed the full report on the example you posted it was in a CRT area that I didn't really care about nor could I control. So it was fine. If it's in your application, especially data structure or widgets that are created and "deleted" a lot, then you need to pay attention to that and track it down.