https://bugs.kde.org/show_bug.cgi?id=494138
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |CONFIRMED Ever confirmed|0 |1 --- Comment #11 from [email protected] --- I've managed to reliably reproduce the VRAM leak and have a much clearer picture of what's happening. The key issue is that VRAM usage spikes every time the ScreenChooserDialog is opened and then closed, even when cancelling the request. The leaked memory is never reclaimed. I recorded a short video to show exactly what's happening. The nvtop graph on the left clearly shows the VRAM spikes corresponding to my actions. You'll notice a jump when the dialog opens, and then a second, much larger jump, the moment it closes. This is repeatable and the memory usage just keeps climbing. https://youtu.be/ho1MU_f69ew To figure out why, I added some qCDebug prints to the ScreencastingStream constructor and destructor in the xdg-desktop-portal-kde master branch. The logs confirmed my suspicion: while many ScreencastingStream objects are created for the previews when the dialog opens, their destructors are never called when the dialog is closed. The C++ objects managing the streams are being leaked. I'm now fairly certain the root cause is an architectural issue with object ownership. It seems the ScreencastingStream objects for the previews are being parented to the global Screencasting singleton within the portal, instead of the QML components in the dialog that request them. Because of this, when the ScreenChooserDialog is destroyed, the C++ stream objects are orphaned and never garbage collected. This also explains the strange two-stage leak. The initial smaller leak on dialog open is from the stream object initialization. The larger leak on dialog close seems to be an asynchronous race condition: KWin finishes preparing the "heavy" video buffers and sends them to the portal after the dialog has already been closed. The portal receives these resources, but the QML components that were supposed to handle them are already gone. With no context to manage them, these buffers get stranded in VRAM. So, the core problem is that the lifecycle of the preview stream resources is not tied to the lifecycle of the ScreenChooserDialog. The fix likely requires ensuring that the component requesting a preview stream (I believe it's TaskManager.ScreencastingRequest in plasma-workspace) is also responsible for explicitly destroying that stream when it is itself destroyed. -- You are receiving this mail because: You are watching all bug changes.
