QMdiSubWindow run-time memory leak
-
Hi all,
I'm a Qt newbie and this is my first post.
I have a problem of run-time memory leak with a simple do-nothing application, a QMainWidow with QToolButton widget inside a QMdiSubWindow. The used memory (view via Task Manager) grows a little when I repeatedly push the button. Sometimes two or three pushes are enough, sometimes ten or a little more are required. If I add a do-nothing QSpinBox, I can view the used memory increasing when I change the value. Sometimes, but not always, the application start eating memory even when I do nothing. In this case, it stop eating memory when the spin box loose the focus and it start again then the spin box get the focus.
The following code generate the problem (I know: in the examples I don't delete the widgets, but this is another story):
@
MainWindow::MainWindow(QWidget parent)
: QMainWindow(parent)
{
QMdiArea mdi=new QMdiArea;this->setCentralWidget(mdi);
QHBoxLayout* ly=new QHBoxLayout;
QToolButton* tb=new QToolButton;
ly->addWidget(tb);QSpinBox* sb=new QSpinBox;
ly->addWidget(sb);QWidget* w=new QWidget;
w->setLayout(ly);
QMdiSubWindow* sw=mdi->addSubWindow(w);
}@
I know that the memory is not immediately returned to the system, but I don't think this is the case: my sample start with 20360K of used memory and can arrive at 21000K after a couple of minute, even without user interaction at all (when the focus is on the spin box).
OS: Windows XP SP2
Qt Version: 4.7.0
Qt Creator: 2.0.0 -
What do you use to measure memory? It can be problem om measurement tool.
-
[quote author="Denis Kormalev" date="1283347708"]What do you use to measure memory? It can be problem om measurement tool.[/quote]
I use the Windows Task Manager. So far as I know, I can trust it. If I put the same controls as a direct child of the main window the memory is stable (well, it jitter a little but it is reasonable).
At first I supposed it is due to the heap management and page granularity, but in this case I suppose that, soon or late, it should stop growing and reuse the already mapped memory.
I tried to wait a while and also stimulate the GUI long time to see if the memory stop growing, but it continues to increase.If I add a slider connected to the spin, moving the slider increase the memory also (and it easy grow to 25M!).
@
QSlider* slider=new QSlider(Qt::Horizontal);
ly->addWidget(slider);connect(slider, SIGNAL(valueChanged(int)), sb, SLOT(setValue(int)));
connect(sb, SIGNAL(valueChanged(int)), slider, SLOT(setValue(int)));
@ -
Windows Task Manager cannot be used to measure memory leaks. It shows something that can be really far from reality (maybe they fixed something in Win7, but for previous versions this statement is true). Better use special tools for memory leeks checking (but also keep in mind that they are too paranoidal and they can have false alarms in correct places).
-
[quote author="Franzk" date="1283406222"]Just because the memory footprint of a program is growing, it doesn't mean there is a memory leak. As Denis stated, the WTM is a rather crude tool and can therefore only really be used for a crude overview. [/quote]
I know WTM is not a good tool for that, but I thinks it can give me an idea of memory usage. Maybe this is not a memory leak, but it sound strange to me that a simple do-nothing application use so much memory and that it increases even if I do nothing. The same do-nothing application implemented as dialog (without the subwindow) has a stable memory usage. Increasing memory footprint dones't mean memory leak, of course, but if it isn't a memory leak, it is memory used somewhere by the application. In this case the application does nothing at all, so I suppose is Qt that is doing something with that memory.
Is that a normal behaviour for a Qt application?
My real-application, with about 64 QSpinBox into a subwindow, refreshed every 250ms, easly eats megabytes. At first I supposed there is a memory leak in my code, even it don't use the freestore, but then I extract the piece of the GUI I had posted. Of couse, maybe I have a problem with my code also.