Memory leak problem
Experiencing possible memory leak in qt 5.7
It can be recreated if loop 2 dif color changes for ui and change color via :
Each time memory grows gradually ,if alter color , if fast timer for color changes, it can grow fast.
Similar to the old post here. https://bugreports.qt.io/browse/QTBUG-17151
Is there some alternative way to work around the memory increase problem if code requires continual change of colors to ui components?
Hi! The bug tracker says that the issue was closed because it was reported to affect an ancient Qt version, not because it's clear if the bug was fixed. So, if you can reproduce it with a current version then it would be the best to reopen the issue.
@Wieland Do you need example code to generate the memory growth?
@Q139 Yes, that would be really helpful :-)
Edit: You can add a comment to QTBUG-17151, attach the source file that reproduces the error, give information about your platform & Qt version and say you request the issue to be reopened.
@Wieland If create QTimer with 1ms or 0ms and run code below it should grow memory fast.
Platfrom : win 7 x64
Qt version : 5.7
Problem occurs in mingw & msvc2013 compilers
ui->xx->setStyleSheet("background-color: black"); // Problem occurs on this line if the ui component is dragged near QDateTimeEdit.
Onto xx needs to be dragged a QDateTimeEdit that intersects , otherwise the growth wont begin.
If it is normal and setStyleSheet for one time use or what to use instead if changing color of ui?
How do you measure the memory consumption? With Valgrind?
@Wieland With windows task manager , no advanced debugging.
If loop it fast, it grows fast.
If comment out the line containing setStyleSheet and do same loop the memory stays stable.
Sry, didn't know Valgrind isn't available on Windows. If it's really a memory leak then there's probably nothing you can do about it right now. Do you need to change the stylesheet only for a single kind of widget or for many? If it's only one simple widget class (e.g. buttons showing some text), then you could work around it by reimplementing the paint event handler.
To add to @Wieland, you could also use a property to select the color and only set the stylesheet once.
It was hard to reconstruct the problem on empty project , the growth was only happening if pushbutton and qdatetimeedit standing on eachother and also the mainwindow needs to have gradient background color.
If one of the conditions not met, the growth wont appear.
The problem may not be fully related to the old bug.
@Q139 It is possible to create a minimum project which could reproduce the problem and open an issue on bug tracker?
Is this not considered a memory leak or problem?
Why is it happening?
Like Thiago wrote, you are creating an application that doesn't run in normal conditions thus you might be artificially creating the problem. Like trying to refresh a UI at 200Hz and stating that it doesn't work is invalid because no system is that fast.
You need to provide an application sample that runs in normal condition and shows the growth, even if it's very slow. Measure it and tell when it happen, even if it's after several hours, that is not a problem.
Everyone can choose the timing for refresh as they like, Tested with slow rate and overnight also, it does not appear to reduce the effect noticably.
Since modern pcs have lots of ram it is not too critical but still strange.
If remove gradiant background or move one ui component away from other , the problem magically dissapears completely.
Also in sanity version made buttons to change those parameters automatically so it can be seen on runtime.