How should I debug event loops (or how to find out where the 5mb memory swing come from?)
-
I am playing around an open source dictionary program, and there is a weird bug: if you put cursor/focus on the search box, there will be a fixed size memory swing occurring a fixed period.
I tried to figure it out multiple times, but no lack.
https://github.com/xiaoyifang/goldendict/issues/232
The problem still exists:
Graph: Focus searchbox by click it → unfocus it → focus it again
I used bytehound to get a better backtrace, but the only thing I get is that the memory swing is about 4.19mb, related to QImage and probably related to some events?
backtrace:
Allocated at: #0 [goldendict] _start [start.S:115] #2 [libc.so.6] 0x00007F2310A3C28F #3 [goldendict] main [main.cc:439] #9 [libglib-2.0.so.0.7400.1] g_main_context_dispatch #10 [libQt6Core.so.6.4.1] 0x00007F231294F527 #11 [libQt6Core.so.6.4.1] QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) #15 [libQt6Widgets.so.6.4.1] QWidgetRepaintManager::paintAndFlush() #16 [libQt6Widgets.so.6.4.1] QWidgetRepaintManager::flush() #18 [libQt6XcbQpa.so.6.4.1] 0x00007F22E452324B #19 [libQt6Gui.so.6.4.1] QPlatformBackingStore::rhiFlush(QWindow*, double, QRegion const&, QPoint const&, QPlatformTextureList*, bool) #20 [libQt6Gui.so.6.4.1] 0x00007F2312E136C5 #21 [libQt6Gui.so.6.4.1] 0x00007F2312E074E3 #26 [libQt6Gui.so.6.4.1] QImageData::create(QSize const&, QImage::Format) #27 [libbytehound.so] malloc [api.rs:294] Deallocated at: #0 [goldendict] _start [start.S:115] #2 [libc.so.6] 0x00007F2310A3C28F #3 [goldendict] main [main.cc:439] #9 [libglib-2.0.so.0.7400.1] g_main_context_dispatch #10 [libQt6Core.so.6.4.1] 0x00007F231294F527 #11 [libQt6Core.so.6.4.1] QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) #15 [libQt6Widgets.so.6.4.1] QWidgetRepaintManager::paintAndFlush() #16 [libQt6Widgets.so.6.4.1] QWidgetRepaintManager::flush() #18 [libQt6XcbQpa.so.6.4.1] 0x00007F22E452324B #21 [libQt6Gui.so.6.4.1] QRhiCommandBuffer::beginPass(QRhiRenderTarget*, QColor const&, QRhiDepthStencilClearValue const&, QRhiResourceUpdateBatch*, QFlags<QRhiCommandBuffer::BeginPassFlag>) #22 [libQt6Gui.so.6.4.1] 0x00007F2313088C43 #23 [libQt6Gui.so.6.4.1] 0x00007F23132263EF #25 [libQt6Gui.so.6.4.1] QImageData::~QImageData() #26 [libbytehound.so] free [api.rs:419] -
It doesn't seem to be specific to focus or concrete widget. It's just repainting the window, so it would be the same if you pressed a button or do anything else that requires a repaint.
As to what's the allocation - I don't know Linux that well or what the rendering backend does there, but it seems it allocates a buffer image. Depending if it's an accelerated surface or not (e.g. OpenGL or Vulkan) and how the update is structured it might need to allocate a temporary buffer to render to on the CPU and then upload it as a texture to the GPU. The size of the buffer would probably be the same size as the window and depends on the format of the surface. For example FullHD RGBA texture would be around 8MB. FullHD RGB just above 5MB etc. See if the size changes if you make the window larger or smaller and that shoud give you an idea.There wasn't really a question from you, but you said it's a "weird bug". I don't think it's a bug at all, just how the backend is implemented. Maybe you can change backends or window managers to avoid it, but, like I said, I don't know much about Linux, so I won't be of much help.
-
It doesn't seem to be specific to focus or concrete widget. It's just repainting the window, so it would be the same if you pressed a button or do anything else that requires a repaint.
As to what's the allocation - I don't know Linux that well or what the rendering backend does there, but it seems it allocates a buffer image. Depending if it's an accelerated surface or not (e.g. OpenGL or Vulkan) and how the update is structured it might need to allocate a temporary buffer to render to on the CPU and then upload it as a texture to the GPU. The size of the buffer would probably be the same size as the window and depends on the format of the surface. For example FullHD RGBA texture would be around 8MB. FullHD RGB just above 5MB etc. See if the size changes if you make the window larger or smaller and that shoud give you an idea.There wasn't really a question from you, but you said it's a "weird bug". I don't think it's a bug at all, just how the backend is implemented. Maybe you can change backends or window managers to avoid it, but, like I said, I don't know much about Linux, so I won't be of much help.
@Chris-Kawa Thank you very much for pointing me to a right direction, and you are absolutely right. I narrowed the problem to the search box's paint event. The cursor blinking is causing the repainting events.
-
S shenlebantongying has marked this topic as solved on
