Version: unspecified (using Devel) OS: Linux When using oxygen-gtk2 with eclipse, the number of GEM objects allocated continues to increase, eventually leading to severe lags and ultimately to a unresponsive desktop. Reproducible: Always Steps to Reproduce: - Use the oxygen-gtk2 theme - Open eclipse, start working - Periodically do cat /sys/kernel/debug/dri/0/i915_gem_objects - Notice constant increase Actual Results: After ca 30mins working with eclipse, I have some 15000 GEM objects allocated. (with an idle desktop, just ca 2000 are allocated). At that level, pointer motion starts to become choppy. If I open an application such as dolphin or gwenview, the desktop freezes completely for 30secs or more. Expected Results: Should not happen. Using another theme (i.e. light-themes), the number of allocated GEM objects stays more or less constant.
First, I have no idea what GEM is. Second, it looks like a memory leak. But oxygen itself is not leaking (there's basically no pointers involved). What could happen is that objects gets allocated and never freed, because they are attached to widgets which themselves are never freed (by Ecclipse). Especially since the same behavior does not happen with other applications. 1/ could you double check that you have no unusual (even if smaller) memory increase (or GEM increase, whatever this thing is) of eclipse over time when using other gtk styles 2/ could you also look at the output of xrestop, overtime, and notably the number of allocated pixmaps. ... and post your observations there. (I'm unfortunately not an eclipse user, and would not even be able to use it for more than 1 minute :)) Hugo
Thanks for your quick reply! GEM is the Graphics Execution Manager, thing which does memory management for intel igp chips. Not knowing too much about it either, but there was this high profile bug [1] which resulted in similar symptoms, though back there it was a GLX bug. As a better reproducer, the accumulation of such objects is evident just by opening and closing context menus in eclipse, without needing to have any document open or do any work at all. By clicking for some minutes, the object count increased from 3k to 10k. Doing the same with the Radiance gtk2 theme, the object count does not increase at all when opening context menus. Looking at xrestop, the number of allocated pixmaps also steadily increases with each right click (some 10 pixmaps, or ca 4k of pixmap memory, for each menu displayed). [1] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/565981
Just noticed, the same happens with oxygen-gtk3, i.e. with audacious: everytime a menu is opened, some 10-20 pixmaps are created. By the way, version numbers: oxygen-gtk-1.2.0-1.fc17.x86_64 oxygen-gtk3-1.0.0-1.fc17.x86_64
I definitly can reproduce the audacious issue with oxygen-gtk3. Working on it. (and in fact, there is a chance that the issue is the same with eclipse + oxygen-gtk2)
ok. Found a serious leak in oxygen-gtk (both gtk2 and gtk3). It causes the issue in audacious, and most likely in eclipse too. (damn). Its about Cairo surfaces being referenced *twice* in copy constructor, effectively resulting in them never being freed. I'm actually surprised we have not been bitten harder by this one. (most likely because copy constructors are used seldom). Anyway, will commit a fix soon for you to test.
Great, thanks!
Hm, I had some similar symptoms with pidgin becoming choppy over time (after some days of usage). I thought it was pidgin's fault, but now it seems it's not.
Git commit d9f358e06ac85110e1b1d9284d1af010186619f2 by Hugo Pereira Da Costa. Committed on 24/01/2012 at 22:45. Pushed by hpereiradacosta into branch '1.2'. removed custom copy constructor and assignment operators, because default ones should work just fine. The copy constructor actually had a bug, resulting in referencing twice the member Cairo surfaces, so that they would effectively never be freed. M +0 -31 src/oxygentileset.cpp M +0 -6 src/oxygentileset.h http://commits.kde.org/oxygen-gtk/d9f358e06ac85110e1b1d9284d1af010186619f2
ok. The first part of the fixed has been pushed to all branches. Now, there will be a second part: Caches, used for animations are being filled too much. Due to this, you would still see large memory increase, from the beginning, untill the cache are full. This is no leak strictly speaking, but might still result in a very large amount of pixmaps being allocated, especially for smooth transitions. In oxygen-qt, we worked around this by only using at most 10 (fixed position) frames per animation, effectively reducing the cache size by about x10. (the number of frames is actually a setable parameter) Will implement this in oxygen-gtk. This should fix it all.
Just build the latest git and is looking good!
Git commit 2c6af31a671208d910643a1025b59eb17f89a357 by Hugo Pereira Da Costa. Committed on 24/01/2012 at 23:14. Pushed by hpereiradacosta into branch '1.2'. Added fixed number of steps of animations, loaded from oxygenrc. Default value is 10, just like for oxygen-qt. M +9 -2 src/animations/oxygentimeline.cpp M +16 -0 src/animations/oxygentimeline.h M +4 -0 src/oxygenqtsettings.cpp http://commits.kde.org/oxygen-gtk/2c6af31a671208d910643a1025b59eb17f89a357
ok. That's the second step. Now things should be just fine in all versions of gtk. Both audacious, and most likely eclipse, should be fine. In fact, performances as a whole should be quite improved. No more growing memory here, and also, the caches needed for animations never grow super large. Please double-check, and close this report if you are happy :) Thanks for reporting ! (that was a major flow, in fact)
Rebuilt again with latest changes -> very happy :) Thanks a lot! Marking as fixed.