QOpenglWidget memory leak
-
@jsulm The code logic should be fine. I encountered this memory leak issue in another project, so I wrote this demo to validate it further. I found that there is also a memory leak in this demo. Currently, I've used Visual Studio's memory tool to analyze it, but haven't identified the problem. Therefore, I'd like to seek help on this matter.
-
-
@xingqun said in QOpenglWidget memory leak:
I've noticed memory leaks even when using the official Qt demo.
Please provide a minimal, compilable example to reproduce this leak.
-
@Christian-Ehrlicher You can compile and run this project. I'm using Qt 5.15.2 + VS2019. Then, compile and run it in Qt Creator. After running, maximize the software, then continuously drag the graphic back and forth with the mouse to keep it refreshing constantly. This way, you can observe the memory continuously increasing in the Task Manager.
-
Not sure if the memory leak reported here was on the CPU side or GPU side but at least regarding GPU memory there are definitely bugs in the implementation and I've seen issues on X11, NV, Qt5.
This is what I found at the time.
https://forum.qt.io/topic/92179/xorg-vram-leak-because-of-qt-opengl-application/12
https://community.khronos.org/t/xorg-vram-leak-because-of-qt-opengl-application/76910/2
https://bugreports.qt.io/browse/QTBUG-69429 -
@SamiV123
Here are a few observations we made during debugging from our end:The higher the screen resolution, the faster the memory leak occurs. This was the direct cause we identified for the issue. When our client's computer with a 4K resolution runs our application, it experiences a memory leak leading to a crash. Therefore, we reproduced the problem using a 4K resolution. Both our custom demo and the official Qt demo consistently exhibit this behavior.
We used Visual Studio's memory snapshot for analysis but didn't find any leaked stack traces.
On machines with NVIDIA dedicated graphics cards, setting the software mode to high performance, thereby ensuring it primarily uses the dedicated GPU for OpenGL rendering, prevents memory leaks.
On machines with Intel integrated graphics, memory accumulation and leaks occur.
I suspect this could be due to the integrated graphics struggling to handle the data, resulting in memory accumulation. However, this is just my speculation. Currently, this issue is quite challenging, and we haven't found a solution yet. -
@xingqun I did quick test with valgrind
==================5.15.2 on Ubuntu 22.04
==556545== LEAK SUMMARY:
==556545== definitely lost: 256 bytes in 1 blocks
==556545== indirectly lost: 32 bytes in 1 blocks
==556545== possibly lost: 0 bytes in 0 blocks
==556545== still reachable: 613,875 bytes in 10,922 blocks
==556545== suppressed: 0 bytes in 0 blocks
==556545== Reachable blocks (those to which a pointer was found) are not shown.
==556545== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==556545==
==556545== For lists of detected and suppressed errors, rerun with: -s
==556545== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)==================6.6.2 on Ubuntu 22.04
==557606== HEAP SUMMARY:
==557606== in use at exit: 346,588 bytes in 3,812 blocks
==557606== total heap usage: 232,769 allocs, 228,957 frees, 1,005,388,571 bytes allocated
==557606==
==557606== LEAK SUMMARY:
==557606== definitely lost: 0 bytes in 0 blocks
==557606== indirectly lost: 0 bytes in 0 blocks
==557606== possibly lost: 0 bytes in 0 blocks
==557606== still reachable: 344,572 bytes in 3,791 blocks
==557606== suppressed: 0 bytes in 0 blocks
==557606== Reachable blocks (those to which a pointer was found) are not shown.
==557606== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==557606==
==557606== For lists of detected and suppressed errors, rerun with: -s
==557606== ERROR SUMMARY: 6 errors from 4 contexts (suppressed: 0 from 0)You may try a higher version of Qt5 or switch to Qt6.
