Created attachment 78720 [details] after Thousands clicking just on buddies menu x memory grow to ~200mb just look at the picture , i just keep clicking on buddies menu on pidgin, and my X process growing up to 200mb (and keep growing). some thing i notice kwin process keep growing just same as X . when i start my system . as normal x just have ~16mb and kwin ~20mb.but as picture show it increase to 200mb and keep increasing !! i try both arch linux default package and kde ftp package (oxygen-gtk2-1.3.2.tar.bz2).
... sorry. The code fix exists, is in git reporsitory (either 1.3 branch or master) but has not been released yet. I'll release oxygen-gtk2-1.3.3 in the comming days so that it hits your distribution soon enough. In the meanwhile you can either - compile the code manually (its rather easy, really) - update cairo (and confirm that this does indeed fix the issue) Cheers, Hugo *** This bug has been marked as a duplicate of bug 316066 ***
thanks and sorry for reporting DUPLICATE bug,
i cloned git repository , i compile both 1.3 and master brunch in two different boot ,but still my memory is non-normal growing for X (exactly same as picture).
Created attachment 78837 [details] branch 1.3 compile dosnt fix problem i just reclick on buddies menu in pidgin , and my x grow from ~20mb to ~150mb , and after taking picture and closing gtk app , my x dosnt growing up
Ruslan, since you are using pidgin extensively, can you confirm/infirm the issue ?
i notice when i set OXYGEN_DEBUG flag, in pidgin when i just open buddies menu or any other pop up menu, whole program crash. systemd-coredump[8473]: Process 8468 (pidgin) dumped core. but not in chromium or tixati.
trying to reproduce the crash now. can you provide a backtrace ? (run pidgin via gdb, then 'bt'), and link the result here (attachment). Thanks ! Hugo
sorry for delay , this is for valgrind pidgin : http://pastebin.ca/2356945 i will paste gdb of course
Git commit d79d95e1070636007ca8c57d98bfbdf1d3d58f82 by Hugo Pereira Da Costa. Committed on 12/04/2013 at 14:54. Pushed by hpereiradacosta into branch '1.3'. fix crash in pidgin when enabling debug, apparently caused by NULL menu items. M +1 -1 src/animations/oxygenanimations.cpp http://commits.kde.org/oxygen-gtk/d79d95e1070636007ca8c57d98bfbdf1d3d58f82
ok nevermind the above the crash I can reproduce and fix. still investigating whether it tells me more about the leak you mention.
crash is fixed. Concerning the leak, I 'seem' to be able to reproduce. investigating.
Git commit 962d36a16d69a828ce1ee195d406d31f845e0c6d by Hugo Pereira Da Costa. Committed on 12/04/2013 at 14:54. Pushed by hpereiradacosta into branch 'gtk3'. fix crash in pidgin when enabling debug, apparently caused by NULL menu items. M +1 -1 src/animations/oxygenanimations.cpp http://commits.kde.org/oxygen-gtk/962d36a16d69a828ce1ee195d406d31f845e0c6d
I take it back. Can't reproduce the leak. here X is pretty stable no matter how often I click on the buddy menu ... what's your "cairo" version ? (mine is: 1.12.x) (not sure about the value of x that I actually have due to packages names) ... I suspect a low level leak in cairo (as was the case for the other bug which I tried to attach this one to). (now, ok, coders always tend to suspect other's code to be at fault whenever there are bugs ;) )
this valgrind pidgin is for my fresh boot , i start with x 14,100mb and end with ~30mb.(and if i continue it will be growing ) http://pastebin.ca/2357037 (i just remove some repetitive line) another important thing i notice it is in just for first time . when again i open pidgin , how much i reclick on menu's , seems x is stable.
Hi again, thanks for the valgrind log :) Now: 1/ I don't think the debug output is very usefull here for detecting leaks (though it obviously is for detecting crashes ;)) 2/ I'd actually be intersted in the output of valgrind, with --leak-check=full to see where the memory is actually lost (the one reported at the end) Cheers, Hugo
Created attachment 78842 [details] pidgin valgrind full check for memory leak
> another important thing i notice it is in just for first time . when again i open pidgin , how much i reclick on menu's , seems x is stable. Couldn't it mean that at first oxygen fills its cache, then after cache size reaches maximum, memory usage stabilizes? Looks like it's intended behavior.
(In reply to comment #17) > > another important thing i notice it is in just for first time . when again i open pidgin , how much i reclick on menu's , seems x is stable. > > Couldn't it mean that at first oxygen fills its cache, then after cache size > reaches maximum, memory usage stabilizes? Looks like it's intended behavior. i agree with this , but problem is memory usage in first time dosent stabilizes any time , it keep just growing up , personally i just going ~250mb of x process after that i tired from clicking , and i think 250mb for X is more than enough .
I can't reproduce. For me Xorg memory usage remains constant ~50M. What's your cairo version?
well, at least some of the leaks in the valgrind log it seems I can fix. e.g.: ==498== 6 bytes in 3 blocks are definitely lost in loss record 197 of 9,137 ==498== at 0x4C2C04B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==498== by 0x7926480: g_malloc (in /usr/lib/libglib-2.0.so.0.3400.3) ==498== by 0x793CD66: g_strndup (in /usr/lib/libglib-2.0.so.0.3400.3) ==498== by 0x7931B23: g_match_info_fetch (in /usr/lib/libglib-2.0.so.0.3400.3) ==498== by 0x13A6EBBB: Oxygen::ColorUtils::Rgba::fromKdeOption(std::string) (oxygenrgba.cpp:100)
(In reply to comment #19) > I can't reproduce. For me Xorg memory usage remains constant ~50M. What's > your cairo version? [rahimi@rahimi ~]$ sudo pacman -Q | grep cairo cairo 1.12.14-3 lib32-cairo 1.12.14-3
Mm... have they broken it again?.. Could you check if this patch makes any difference: diff --git a/src/oxygentileset.cpp b/src/oxygentileset.cpp index 7e4c816..4c9430b 100644 --- a/src/oxygentileset.cpp +++ b/src/oxygentileset.cpp @@ -185,7 +185,7 @@ namespace Oxygen } else { // Bug 316066 - #if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 12, 4) + #if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(2, 12, 4) Cairo::Surface tile( cairo_surface_create_for_rectangle( source, sx, sy, sw, sh ) ); #else Cairo::Surface tile( cairo_surface_create_similar( source, CAIRO_CONTENT_COLOR_ALPHA, sw, sh ) );
Git commit 687f32ad7243733a8185a5e2d4a6063bb3e607c4 by Hugo Pereira Da Costa. Committed on 12/04/2013 at 17:41. Pushed by hpereiradacosta into branch '1.3'. Fixed leak when parsing colors from kde config free result from g_spawn_command_line_sync Free icon source after insertion in icon set Fix another leak due to g_spawn_command_line_sync M +1 -0 src/oxygengtkicons.cpp M +6 -2 src/oxygenqtsettings.cpp M +8 -2 src/oxygenrgba.cpp http://commits.kde.org/oxygen-gtk/687f32ad7243733a8185a5e2d4a6063bb3e607c4
Git commit 51fd533df5797df39b03bc7286a6ace8ee5a170d by Hugo Pereira Da Costa. Committed on 12/04/2013 at 17:41. Pushed by hpereiradacosta into branch 'gtk3'. Fixed leak when parsing colors from kde config free result from g_spawn_command_line_sync Free icon source after insertion in icon set Fix another leak due to g_spawn_command_line_sync M +1 -0 src/oxygengtkicons.cpp M +6 -2 src/oxygenqtsettings.cpp M +8 -2 src/oxygenrgba.cpp http://commits.kde.org/oxygen-gtk/51fd533df5797df39b03bc7286a6ace8ee5a170d
... so. I have fixed all the oxygen related 'definitly lost' warnings from the valgrind log. Now: don't expect much improvement. The memory growth that you see is in X, not in pidgin. Meaning that it can't be seen by valgrind (unless you valgrind 'x', but that would not help either). I have not spotted any "indirect" leak in oxygen-gtk seen by valgrind that would result in an X resource leak (namely creating unfreed pixmap). So ... not easy ...
now i can confirm growing speed is more slow. some thing like 200k for 3 click . it is much much better than before , but i think still there is low level bug . and i think it doesn't related with oxygen-gtk. should i change this bug to FIXED ??
@nRahimi Please check the patch from comment 22.
(In reply to comment #32) > @nRahimi > Please check the patch from comment 22. still same
from today i work a lot with gtk app . i think this bug is not related to oxygen-gtk , it is some low level stuff(maybe bug in cairo or some other thing).oxygen gtk is stable and i change bug to RESOLVED , INVALID. thank for your helping Hugo and Ruslan