Created attachment 26275 [details] XorgLog.txt Forwarding this bug from a ubuntu reporter: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/360319 [Problem] Running Jaunty, fully updated, intel X4500MHD chip with EXA acceleration has a memory leak that eventually uses all available system ram, and causes constant swapping leading my system to grind to a halt. The same thing occurs with UXA rendering, although it seems to happen faster with UXA. (We've had several people mention having memory leak issues on UXA and on EXA, so perhaps this is an instance of another more generic bug?) This was also tested against 2.7.0 (others have reported it against 2.7.1 and 2.7.99, so it's believed not fixed yet). ProblemType: Bug Architecture: amd64 DistroRelease: Ubuntu 9.04 Package: xserver-xorg-video-intel 2:2.6.3-0ubuntu9 ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/usr/bin/zsh ProcVersion: Linux version 2.6.28-11-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #41-Ubuntu SMP Wed Apr 8 04:39:23 UTC 2009 SourcePackage: xserver-xorg-video-intel Uname: Linux 2.6.28-11-generic x86_64 [lspci] 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Lenovo Device [17aa:20e0] 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) Subsystem: Lenovo Device [17aa:20e4]
Created attachment 26276 [details] XorgLogOld.txt
distro: Ubuntu architecture: x86_64 kernel: 2.6.28-11-generic xserver-xorg: 1:7.4~5ubuntu18 mesa: 7.4-0ubuntu1 libdrm: 2.4.5-0ubuntu4 -intel: 2:2.6.3-0ubuntu9 -ati: 1:6.12.1-0ubuntu2
There is definitely a system memory leak from using UXA acceleration with OpenGL compositing. In the freedesktop bugzilla I can see #20766 #21770 #18820 #20704 which all seem to be the same issue. I am running on an Eee Box B202 Atom with an Intel 945GM. I have tried 2.7.1 and 2.7.99 and the latest git revision, all exhibiting the same leak (in GEM objects). I have also tried the latest git revisions of Mesa, libdrm and Xorg. I have a small example using Clutter and GTK+ which demonstrates the leak with hopefully the minimum of code - I'll add the attachment after this comment. The bug is also referenced in other bug trackers: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/360319 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/367377 You can also see a few on Moblin: http://bugzilla.moblin.org/buglist.cgi?quicksearch=leak I've been trying to track this down for quite a while and it looks like it is related to the glXBindTexImageEXT call and it not being released with glXReleaseTexImageEXT.
Created attachment 26280 [details] A simple test case using GTK+ and Clutter. This is an example that exercises the leak in GEM objects. It leaks about ten windows worth on each execution. Running this with Valgrind and filtering through the false positives I did find: ==3627== 3,520,000 bytes in 11 blocks are still reachable in loss record 2,603 of 2,603 ==3627== at 0x4026FDE: malloc (vg_replace_malloc.c:207) ==3627== by 0x53BE86A: _mesa_soft_renderbuffer_storage (renderbuffer.c:1202) ==3627== by 0x5395964: _mesa_resize_framebuffer (framebuffer.c:285) ==3627== by 0x5365579: intel_resize_buffers (intel_fbo.c:260) ==3627== by 0x530AC39: driUpdateFramebufferSize (drirenderbuffer.c:211) ==3627== by 0x532DC90: intel_update_renderbuffers (intel_context.c:383) ==3627== by 0x5315B90: intelSetTexBuffer2 (intel_tex_image.c:742) ==3627== by 0x46B02D6: __glXBindTexImageEXT (glxcmds.c:2639) ==3627== by 0x463A668: clutter_glx_texture_pixmap_update_area (clutter-glx-texture-pixmap.c:798) ==3627== by 0x463AD0C: create_cogl_texture (clutter-glx-texture-pixmap.c:375) ==3627== by 0x463B184: clutter_glx_texture_pixmap_notify (clutter-glx-texture-pixmap.c:729) ==3627== by 0x491DABB: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531) I ran valgrind using the following commandline and then used the software X compositing that does not leak and compared the results: G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-modules valgrind --leak-check=full --track-origins=yes --leak-resolution=high --show-reachable=yes -v --suppressions=gtk.suppression ./simple The build and running instructions are in the comments of the example.
I see this too on my Samsung NC 10.
I wonder if this is really a dupe of 20704? There seem to be quite a few leaks...
The leak in the test program seems fixed in Git, probably by commit d027e8feff7d38cccadc6aaccc0454b21ce4dca0 in mesa_7_5_branch and master.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.