Bug 357800 - Huge leak on X on Kate/Kwrite etc
Summary: Huge leak on X on Kate/Kwrite etc
Alias: None
Product: Breeze
Classification: Unclassified
Component: QStyle (show other bugs)
Version: 5.5.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL: https://youtu.be/IgGnb44NCvA
Depends on:
Reported: 2016-01-10 16:55 UTC by Anthony Fieroni
Modified: 2020-06-29 10:55 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:

possible patch (29.78 KB, patch)
2016-01-11 14:20 UTC, Hugo Pereira Da Costa

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Fieroni 2016-01-10 16:55:39 UTC
Refers to https://bugs.kde.org/show_bug.cgi?id=357360 https://bugs.kde.org/show_bug.cgi?id=357725

Reproducible: Always

Steps to Reproduce:
1. Apply breeze in Application style
2. for i in {1..10}; do kwrite & done (Huge ram Xorg usage)
3. Close all kwrite instances, not resource clean
4. Run again for i in {1..10}; do kwrite & done (even more leaks)

Actual Results:  
Huge ram in Xorg, not present in any other style (Oxygen, Fusion, etc.)

Expected Results:  
No leaks
Comment 1 Hugo Pereira Da Costa 2016-01-10 17:15:08 UTC

Thanks for reporting.
But please quantify "huge"
I cannot reproduce here with the provided instructions:

top reports: 
before starting 10 kwrite
25800 root      20   0  279m  69m  44m S    1  1.8   1:09.16 X                                                 

after starting 10 kwrite
25800 root      20   0  357m 145m 120m S    5  3.8   1:09.97 X                                                 

after closing the 10 kwrite
25800 root      20   0  278m  69m  44m R    4  1.8   1:10.85 X                                                 

Comment 2 Hugo Pereira Da Costa 2016-01-10 17:16:22 UTC
... or am I not looking at the right quantity ?
Comment 3 Hugo Pereira Da Costa 2016-01-10 17:18:19 UTC
(though now I am only using Qt-5.5.1)
Comment 4 Anthony Fieroni 2016-01-10 17:41:23 UTC
Without leak -> http://oi63.tinypic.com/t4zajt.jpg
With leak -> http://oi64.tinypic.com/2h5mt4x.jpg
Huge is really HUGE > 500MB on 2 starts
Comment 5 Hugo Pereira Da Costa 2016-01-10 17:59:17 UTC
Thanks for the screenshots 
unfortunately no luck at reproducing still, with ksysguard, this using either breeze from 5.5.3 (same as you) or breeze from master.
Note also that I would have no clue where breeze would allocate 250 Mb of data of any kind per instance ... 
Could you try compiling breeze from "master" rather than the branch and reporte if the issue persists ? there have been 'weird' issues at widget initialization between 5.5.3 and master, which i could not all reproduce, but 'fixed' on the machines where the problem occured, so it might be worth a try for you too.
Compiling breeze from source should not be too big a deal, but don't hesitate to ask if you need how-to's.
Comment 6 Anthony Fieroni 2016-01-10 18:22:23 UTC
You cannot expect normal users to use git master, don't you think? Yeah, i'm programmer, compile and run master - no leaks at all. BUT all from 5.4.90 to 5.5.3 has leaks like in pictures above, now backport it to 5.5 brach especially 5.5.3
PS New artwork is quite nice :)
Comment 7 Hugo Pereira Da Costa 2016-01-10 18:51:14 UTC
(In reply to Anthony from comment #6)
> You cannot expect normal users to use git master, don't you think? Yeah, i'm
> programmer, compile and run master - no leaks at all. BUT all from 5.4.90 to
> 5.5.3 has leaks like in pictures above, now backport it to 5.5 brach
> especially 5.5.3
> PS New artwork is quite nice :)

I repeat: I do not have the leak when running 5.5.3 either
so i would not know what to backport.
I cannot fix a bug that I cannot reproduce.
Only you, who can reproduce the bug, can help me fix it. 
Hence my suggestion to try with more recent code. If this indeed would fix your problem, next step would be git bisect. 
Then I would be able to identify which change creates the issue (which I cannot reproduce), and would be able to either backport (indeed), or provide a patch, or investigate further (with your help).
In the meanwhile, there is not much I can do, sorry.
Comment 8 Anthony Fieroni 2016-01-10 19:07:30 UTC
I don't make fake picture to wrote bug reports, do you agree it? Tested on Arch and KaOS same result as above.
Comment 9 Anthony Fieroni 2016-01-10 19:12:09 UTC
Video to sure i'm not lying
Comment 10 Hugo Pereira Da Costa 2016-01-11 12:53:19 UTC

I never doubted that the problem you report is true, nor did I say anywhere that I did not believe you.
I merely stated that on my machine, I cannot reproduce this issue, this whether I use the latest version of breeze, or the same as you. Now there can be many reasons for this discrepancy. Qt version, X version, graphics card driver, upstream frameworks version, and what not. 
But whatever the reason, without further help on your side, there is no way I can fix this bug myself, since I do not see it (on the only machine I have). 
In order to move forward I have no choice but wait either for your help, or for the help from someone else who is experiencing the same problem as you. 
In the meanwhile and if you cannot provide the help I need (for whatever reason), and if you still want a usable machine, I'll recommend to switch to oxygen or fusion, or whatever. 

Best regards,

Comment 11 Anthony Fieroni 2016-01-11 13:03:23 UTC
Arch Linux - Qt 5.5.1 xcb 1.11.1 kf 5.18 Xorg 1.18
KaOS - Qt 5.5.1 xcb 1.11.1 kf 5.18 Xorg 1.17.4
Rosa Linux - Qt 5.5.1 xcb 1.9.1 kf 5.17 Xorg 1.15.2
Same hardware - e350 radeon (oss) what else?
No issue from 5.1.1 to 5.4.90 and with master, issues with all 5.4.90 to 5.5.3 only with Breeze.
Comment 12 Hugo Pereira Da Costa 2016-01-11 13:06:15 UTC
Thanks for the info.
So, for Qt, I have same as you, for kf5 I have master, xcb, 1.10 and Xorg 1.14
Graphics card, intel.
Cannot upgrade xcb and Xorg, change hardware, and cannot downgrade kf5 easily.
Comment 13 Anthony Fieroni 2016-01-11 13:38:30 UTC
What is more "easy" to see
diff between 5.4.3 with 5.4.90
or 5.5.3 with master?
Comment 14 Hugo Pereira Da Costa 2016-01-11 13:44:56 UTC
Wait wait, I am confused, 
you did test with master (for breeze), and the issue is gone ? 
If yes, sorry I read too fast, and probably know what the issue come from.
So: you confirm that issue is gone with breeze master, on your side too ?
Comment 15 Anthony Fieroni 2016-01-11 13:59:44 UTC
Yes, master has no leak at all. Only branch 5.5 is affected.
Comment 16 Hugo Pereira Da Costa 2016-01-11 14:03:55 UTC
Thanks ! That helps. 
Apologies, for not catching that up before.
I "think" I might know where the issue come from then. If I post a patch here (to breeze only), would you be ok to test it on top of 5.5.3, before I backport ? 
Otherwise, I can try backport blindly.

Comment 17 Anthony Fieroni 2016-01-11 14:10:43 UTC
I will test it.
Comment 18 Hugo Pereira Da Costa 2016-01-11 14:20:00 UTC
Created attachment 96588 [details]
possible patch

Here you go.
Thanks for testing and reporting back. 
Make sure to keep a copy of the code (either manually or via git), before applying the patch because it is somewhat invasive (for breeze)
I have tested that the code compiles and runs fine though, after applying the patch on top of 5.5.3, so it should at least 'not be worse' than what you have now.
Comment 19 Anthony Fieroni 2016-01-11 17:29:40 UTC
Yes, patch works, no leaks. Why master is about 10MB smaller, if can remove more uneeded code, i will test :)
Comment 20 Hugo Pereira Da Costa 2016-01-11 19:24:09 UTC
(In reply to Anthony from comment #19)
> Why master is about 10MB smaller, if can remove
> more uneeded code, i will test :)
No clue. But better not fix something that is not broken.
Anyway, thanks for helping on this.
I have backported all the changes corresponding to the patch you tested to Plasma/5.5 so that the next release (5.5.4) should be alright.
Closing as fixed.


Comment 21 Elizabeth Myers 2016-01-15 04:51:35 UTC

It is more than just Kate and KWrite. I also experience this big leak. The offending revision through bisection (thanks to awilfox on freenode) is 6d852f30a1f2c1988359d4e0cdb21e2f1714a6bd. The leak does not exist in master as the code in question was removed.

I hope this helps.
Comment 22 Anthony Fieroni 2016-01-21 19:14:13 UTC
I notice more leaks. Master WORKS without leaks.
1. Apply other style except breeze in Application style
2. Apply breeze in Application style
3. Leaks on X, not so aggressive, but make usage *2
Comment 23 Anthony Fieroni 2016-01-24 05:25:45 UTC
Master has same leaks on applying application style.
Comment 24 David Edmundson 2016-01-27 18:42:12 UTC
Anthony, so what's the current status? 
You said it doesn't leak, then said it does.

Do you have a trace of this leak?
Comment 25 Anthony Fieroni 2016-01-27 18:55:46 UTC
X leaks are difficult to trace, if you know easy way :) Yes, leak still present only on applying breeze style in systemsettings. First apply Oxygen or other then apply breeze Xorg Ram usage *2. Same branch 5.5 and master has same leak.
Comment 26 Anthony Fieroni 2016-01-28 18:08:14 UTC
If Breeze set color scheme i can notice color setting cause a leak *2 ram seems bug in color palette?
Comment 27 Anthony Fieroni 2016-02-08 07:40:21 UTC
To make new bug request for color settings
systemsettings5 -> color -> apply color scheme (no matter what) Xorg ram *2
Comment 28 Kai Uwe Broulik 2016-02-27 09:20:16 UTC
Since I switched to an AMD GPU with the Radeon driver I also get huge RAM consumption of X, after two days of uptime (leaving the machine on over night) it consumes 5 GB! Note that this is a Plasma 4 machine but I am using the Breeze widget theme (Qt 4 variant) there too.
Comment 29 Hugo Pereira Da Costa 2016-02-27 10:45:43 UTC
Hi Kai, Anthony
Sorry to say, but this bug report is a mess.
- First the original title is too generic and the actual problem is referred to is _fixed_
- second, other issues (with the same symptom - large X memory-, but different trigger conditions (change of color palette, change of widget theme, or - for kai- nothing, just long uptime), have been appended, and I can't make anything out of it. 
We need to clean this up;
1/ I will try reproduce the issue with switching coloscheme, widget style. But please move this to a separater bug report. When doing so, please make the title explicit enough, so that other unrelated issues do not get appended there. 
2/ kai: unless this is related to the same modus opperandi as describe in the first comment, this should also go to a separate bug report, also: related to the Qt4 variant. Also would be nice to know if you have the same issue with other widgets themes (oxygen, plastique, etc.)
Could well be simply a driver issue (leaks in X are quite often this, sadly. For instance, in the past we have had huge issues with oxygen and nvidia proprietary drivers).

3) then, when the "new things" are moved to their right place, we can _again_ close this bug report (which _is_ fixed, as far as I can tell). And I can happily focus on the new ones.


Comment 30 Anthony Fieroni 2016-02-29 08:25:03 UTC
I make a review https://git.reviewboard.kde.org/r/127204/
The leak is in [QApplication/QGuiApplication] setPalette, how to fix in Qt i have no idea.
Comment 31 Kai Uwe Broulik 2016-02-29 11:42:56 UTC
I now ran for a couple of hours with Oxygen and I already have 1,6 GiB of RAM usage for X and this is Plasma 4.x, so I'm not sure this is an issue on our side?
Comment 32 Hugo Pereira Da Costa 2016-02-29 12:08:19 UTC
Hi Kai,
Thanks ! thats useful.
Now oxygen and breeze share a lot of code. Would be nice if you could do the same test with ... plastique. This is a 'pure QT4' widget theme, so that it would at least put me completely off the hook.

Thanks in advance,

Comment 33 Anthony Fieroni 2016-03-19 18:09:43 UTC
Present in Qt 5.6 setPalette or radeon oss specific issue ?
Comment 34 Martin Flöser 2016-09-12 19:48:26 UTC
No new replies since March - I assume this issue is fixed and not critical any more?
Comment 35 Anthony Fieroni 2016-09-13 03:53:40 UTC
It's Qt issue in setPalette, i can confirm it on radeon oss and intel. Still present but since palettehelper is removed it has leak only when new colors are applied. It can be closed since it's not KDE related.
Comment 36 Noah Davis 2020-06-29 10:55:02 UTC
Regardless of where it was fixed, this appears to be fixed. I cannot reproduce the bug with Qt 5.15, Breeze 5.19.80 or Kate 20.07.70.