Memory leak on some desktop environments

[shlyakpavel]

In less than 19 minutes it can take more memory than gnome shell

https://github.com/lxqt/qps/pull/149 helped a little, but there is still a huge leak left somewhere else. My proposal is to track everything regarding the leaks here.

[tsujan]

Under Linux+LXQt, it's only 22 MiB after 2 hours. I'll continue using it...

My proposal is to track everything regarding the leaks here.

Definitely.

[shlyakpavel]

Under Linux+LXQt, it's only 22 MiB after 2 hours. I'll continue using it...

Did you try changing update period to 1ms? :D

[tsujan]

For real usage? No. I set it to 500ms and left it in the systray.

But I tested with 10ms while making the patch. I saw a "leak" but it stopped at ~20 MiB. I removed the graph as icon and it stopped at the beginning. So, IMO, it was about how setIcon works in Qt (for systray and the main window).

[tsujan]

Please remove trayicon->setIcon(*pm); and setWindowIcon(*pm); from Qps::set_load_icon() and test again! That might make it easier to find the cause.

[shlyakpavel]

https://programmersexception.blogspot.com/2019/04/memory-leak-con-qicon-en-qt-594-y.html This guy states that QIcon(qpixmap) solves the problem. Moreover, according to https://doc.qt.io/qt-5/qicon.html it's us who use qicon in inproper way. I will dig it deeper in the evening

[shlyakpavel]

In other words We make qpixmap pointer, use it in qicon, it is being copied. When the qpixmap is copied, qicon is correctly used and destroyed. QPixmap is left in the memory.

[tsujan]

This guy states that QIcon(qpixmap) solves the problem.

I'd tried it to no avail but please test it.

it's us who use qicon in inproper way.

I haven't seen such a usage of QIcon anywhere else but I don't think it's wrong.

We make qpixmap pointer,

I'd changed that by changing a few functions (I mean I removed the pointer) but it made no difference.

[tsujan]

BTW, here, the memory usage is 28 MiB now (after ~4 hours).

[tsujan]

OK, it really stopped at 28 MiB (qps shows 28 and gnome-system-monitor shows 28.4 for an hour; I checked several times) — which is very good because I'd opened some of its dialogs.

So, there's no (detectable) memory leak here.

Why it uses so much memory under gnome-shell, I have no idea but memory usage isn't determined by a single factor.

[shlyakpavel]

Linux+LXQt

Tested here on fresh Lubuntu,~~ it's the same as it was on Gnome~~

Please remove trayicon->setIcon(*pm); and setWindowIcon(*pm); from Qps::set_load_icon() and test again! That might make it easier to find the cause.

The leak has gone this way!

[shlyakpavel]

Stopped on 29mb in a couple of minutes (git master on LXQt)

[tsujan]

Here, it's still 28 MiB — more precisely, 28.4. I'm starting to trust this app :) It can be left in systray without problem. No memory leak at all.

We should see what's the difference between our use cases. One thing is your 1-ms update interval. I think even 250 ms is too short for a real use case and we should correct that spin-box.

Other things can be gnome or even the virtual machine (I use it with the real computer).

[shlyakpavel]

Other things can be gnome

Looks much like that

or even the virtual machine (I use it with the real computer).

It stops at 29Mib on the same VM with LXQt so it's not the point

[tsujan]

It stops at 29Mib on the same VM with LXQt so it's not the point

Oh, I didn't see your other comment. Good!

Please close this if you agree with me that there's no leak.

[tsujan]

Ha ha.... Gnome is the most nonstandard DE. It even doesn't have a systray.

[shlyakpavel]

Please close this if you agree with me that there's no leak.

Is it possible that leak on gnome is a qps fault? I also wanna test this on KDE and Xfce

[tsujan]

Is it possible that leak on gnome is a qps fault?

I really doubt that. But there's no harm in leaving this open.

[shlyakpavel]

It even doesn't have a systray.

But QPS has a tray icon on gnome anyway (look at my screenshot)...

[tsujan]

That's not the tray icon; it's the window icon. Gnome doesn't have a tray anymore -- at least, not its latest version. I won't be surprised if they remove the panel, icons, texts and everything after a few years ;)

[agaida]

Gnome has no default tray handling anymore - it is now a more or less (to be honest less) working plugin that provided a systray - The reason why it work in Ubuntu: They don't released with the latest Gnome exactly for that reason - damn, @tsujan was faster :sunglasses:

[tsujan]

A gnome-shell extension, probably. It'll break with the next Gnome update.

[shlyakpavel]

@agaida could you please answer my issue about Russian translation?

[shlyakpavel]

LXDE shows the same thing as gnome. It's a qps bug. It's the same on update period > 100ms. Just takes a bit more time to leak

[tsujan]

It's a qps bug.

I'm not sure at all. It can be caused by the Qt icon-engine used in GTK environments -- I don't know what it is.

I have Gnome on my other laptop; will test under it later.

[ghost]

I'm running Ubuntu MATE 19.04 using qps from master, and after running for a little over an hour it reports itself as using (only) 47MB, while mate-system-monitor reports it as using 110.6 MB.

Despite having 24GB of RAM, I was unable to open new programs till I closed a few open ones, which never happened before on this computer.

Additionally, I was unable to open new terminal sessions with mate-terminal until I killed qps, which locked up my computer for several minutes before dying.

The following lines appear in .xsesion-errors whe nI try to open mate-terminal:

** (mate-terminal:9467): WARNING **: 20:49:56.530: Unable to connect to dbus: GDBus.Error:org.freedesktop.DBus.Error.LimitsExceeded: Failed to determine seats of user "1000": Too many open files
Window manager warning: Log level 128: posix_spawn avoided (automatic reaping requested) (fd close requested) (child_setup specified) 

These lines show up many times during the time-span that qps was open, sometimes with a different process name, and sometimes without any process name.

[tsujan]

@plonibarploni If you open a bug report at LXQt, please avoid general and vague descriptions like the above one.

[tsujan]

@shlyakpavel I tested with gnome-shell 3.32.2+11 under Manajro (almost Arch) minutes ago: qps's memory usage stopped at 25 MiB when I gave it a 10-ms update interval. gnome-system-monitor showed the same number.

I'm afraid the cause of your problem should be somewhere else (I suspect the virtual machine).

EDIT: Who knows? The cause may be in older Gnome versions too.

[shlyakpavel]

I'm afraid the cause of your problem should be somewhere else (I suspect the virtual machine).

Then I'll try to install linux on my Mac natively. Seems to be challenging, tough

EDIT: Who knows? The cause may be in older Gnome versions too.

But lxde was also affected!

[shlyakpavel]

A very real screenshot on my very real machine showing a very real leak. And also showing that qps is not ready for hidpi. The issue is by no way related to VM

[tsujan]

The issue is by no way related to VM

Then, you should find to what it is related. As I said, it's not reproducible here, with 2 laptops and under 2 different DEs.

[tsujan]

And also showing that qps is not ready for hidpi

No it isn't because no one set Qt::AA_UseHighDpiPixmaps to true for it:

As I mentioned elsewhere, the GUI needs rewriting; the widgets and icons are nonstandard.

[tsujan]

@shlyakpavel

To make sure that this is about Qt's pixmap cache and not a leak, I set:

QPixmapCache::setCacheLimit(1);

at the beginning of Qps c-tor (in qps.cpp). The memory usage didn't change from start (10 MiB).

You could test that in the DEs where you think there's a memory leak.

NOTE: The default cache limit is 10240 KB.

[shlyakpavel]

Please remove trayicon->setIcon(*pm); and setWindowIcon(*pm); from Qps::set_load_icon() and test again! That might make it easier to find the cause.

The leak has gone this way!

No, no and no. This doesn't help here on GNOME. But commenting out the whole set_load_icon() function makes the leak disappear P. S. Crazy things happening here. Leak comes and goes. Let me dig dipper

[shlyakpavel]

I'm now 100% sure that return QSystemTrayIcon::isSystemTrayAvailable(); in TrayIcon::hasSysTray() causes the leak on my system. If I replace it with "return true" or "return false" everything is fine. Perhaps we should call it once the program is started and then store the value instead of calling it on every refresh. Where to file a bug for it?)

[tsujan]

That may be a bug in the Qt plugins of those DEs (with the versions you have) because isSystemTrayAvailable shouldn't cause any memory leak but yes, there's no need to call hasSysTray continuously, especially when calling it once fixes the memory leak you see.

However, it's preferable to wait for systray at startup, in the way FeatherNotes does it -- as far as remember, I implemented it in LXQt notifications too.