Hi!

I can't see such a drastic increase in plasmashell memory usage, however that might be due to different nvidia driver version. Still, it could just be something else than the graphics driver.

Would it be possible for you to run plasmashell under valgrind? You need debug info for plasmashell and libraries to get usable results.

(In reply to Jiri Palecek from comment #1)
> Hi!
> 
> I can't see such a drastic increase in plasmashell memory usage, however
> that might be due to different nvidia driver version. Still, it could just
> be something else than the graphics driver.
> 
> Would it be possible for you to run plasmashell under valgrind? You need
> debug info for plasmashell and libraries to get usable results.

I upgraded to KDE Plasma 5.22.1, Nvidia driver 460.84 and kernel 5.12.0 yesterday to check if the problem still occurs before replying to you, but now, after around 10h of uptime, plasmashell memory usage still sits at about 140 MB. So, I consider this to be resolved. Marking as "fixed", but I'm not sure if was Plasma, since I upgraded everything at once.

It's not fixed. Turns out a lot of waiting isn't guaranteed to trigger this issue.

Here is the Valgrind report: https://grzesiek11.stary.pc.pl/files/texts/436900_valgrind.log (~80 MiB, be warned).

I have no idea if I had done this right, I just copy-pasted the command found on the Wiki ('valgrind --leak-check=full --show-reachable=yes --track-origins=yes --trace-children=yes --log-file=plasmashell.log plasmashell') and left it overnight.

plasmashell became very slow and unresponsive (which I guess is how Valgrind works), so I didn't use it at all and started everything from Konsole (that was not started by plasmashell, so it wouldn't be it's child). I don't know if I reproduced the issue, since Valgrind replaces the plasmashell process and it used 1.1 GiB at start (it grew to 1.7 GiB when I stopped it).

(In reply to Grzesiek11 from comment #3)
> Here is the Valgrind report:
> https://grzesiek11.stary.pc.pl/files/texts/436900_valgrind.log (~80 MiB, be
> warned).

Thank you. 80Mb, that's nothing :). Even emacs loads it.

> I have no idea if I had done this right, I just copy-pasted the command
> found on the Wiki ('valgrind --leak-check=full --show-reachable=yes
> --track-origins=yes --trace-children=yes --log-file=plasmashell.log
> plasmashell') and left it overnight.

That's good, only the backtraces stop just short before showing useful info, so I'd like you to do it again. For the command:

- --trace-children=yes is unnecessary, I don't think this has anything to do with children, and also, it prevents valgrind from tracing chromium ;)

- --track-origins=yes does nothing for leaks

However, I'd like you to add --num-callers=30, because some of the stack traces are too shallow, they don't go beyond the nvidia driver. So the command should be:

valgrind --leak-check=full --show-reachable=yes --num-callers=30 --log-file=plasmashell.log plasmashell

However, most of all, to get useful backtraces, you need the debugging infos for all the executables. The most suspicious for me is this record:

==103236== 28,516,944 bytes in 4 blocks are possibly lost in loss record 54,997 of 54,997
==103236==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==103236==    by 0x625404D: QImageData::create(QSize const&, QImage::Format) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==103236==    by 0x625426A: QImage::QImage(QSize const&, QImage::Format) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==103236==    by 0x62BFBFF: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==103236==    by 0x6274B18: QImageReader::read(QImage*) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==103236==    by 0x6275294: QImageReader::read() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==103236==    by 0x625E3A7: QImage::fromData(unsigned char const*, int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==103236==    by 0x6225523: QInternalMimeData::retrieveData(QString const&, QVariant::Type) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==103236==    by 0x6A6198F: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.2)
==103236==    by 0x6A627B8: QMimeData::imageData() const (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.2)
==103236==    by 0x259CB337: ??? (in /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_clipboard.so)
==103236==    by 0x259BA854: ??? (in /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_clipboard.so)

but 0x259CB337: ??? (in /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_clipboard.so) doesn't tell me much.

To get debug symbols, since you're on debian, follow these instructions: https://wiki.debian.org/HowToGetABacktrace, mostly the part "Installing the debugging symbols". Particular debugging packages you need are:

- plasma-workspace-dbgsym for plasmashell and plasma_engine_clipboard.so
- libkf5plasmaquick5-dbgsym for libKF5PlasmaQuick.so.5.83.0
- libkf5plasma5-dbgsym for libKF5Plasma.so.5.83.0

and maybe

- libqt5core5a-dbgsym
- libqt5quick5-dbgsym
- libqt5qml5-dbgsym

> plasmashell became very slow and unresponsive (which I guess is how Valgrind
> works), 

Sadly that's the way it is.

> so I didn't use it at all and started everything from Konsole (that
> was not started by plasmashell, so it wouldn't be it's child). I don't know

Please try to interact with plasma as usual. The leak might be tied to some user actions. Or alternatively, think what could be contributing to the problem so it can be reproduced. If it is tied to the clipboard, do you use it specifically? Do you use some special widgets? etc.

> if I reproduced the issue, since Valgrind replaces the plasmashell process
> and it used 1.1 GiB at start (it grew to 1.7 GiB when I stopped it).

Yeah that's OK, valgrind uses a lot for its bookkeeping.

(In reply to Jiri Palecek from comment #4)
> That's good, only the backtraces stop just short before showing useful info,
> so I'd like you to do it again. [...]

Okay, I installed more debug symbols, adjusted the Valgrind args and here is the result:

https://grzesiek11.stary.pc.pl/files/texts/436900_valgrind_2.log

It's half a GiB this time... Hopefully my server can handle it.

> Please try to interact with plasma as usual. The leak might be tied to some
> user actions.

This time I used it normally, it was workable since it didn't trace children. I also left it for one night.

> Or alternatively, think what could be contributing to the
> problem so it can be reproduced. If it is tied to the clipboard, do you use
> it specifically? Do you use some special widgets? etc.

My setup is pretty vanilla, so I don't know what could be the problem. I have bigger than default clipboard history (1000 entries), but clearing it only sets me back a couple of MiB in terms of memory usage. Hopefully it will be possible to figure it out from the log.

Hello and thank you again for the bug report! Unfortunately we were not able to address it yet, nor even manage to reproduce the issue ourselves. Can we ask you to please check if this issue is still happening with Plasma 5.27?

If it is, please change the status to REPORTED. Thanks a lot!

Hi, I actually have a session of Plasma 5.27 up for over 20 days now on this exact machine and configuration, and it's memory usage is at a steady 700 MiB! I actually forgot about this bug report, since I don't have any issues with memory usage now.

So, for whatever reason, this is now fixed. Great!

My current system information, for reference:
Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Kernel Version: 6.4.0-4-amd64 (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 2600 Six-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 660/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B450M DS3H
Nvidia Driver Version: 470.199.02