Activity log for bug #565981

Date Who What changed Old value New value Message
2010-04-18 14:13:00 Tormod Volden bug added bug
2010-04-18 14:13:00 Tormod Volden attachment added Dependencies.txt http://launchpadlibrarian.net/44692544/Dependencies.txt
2010-04-18 14:13:00 Tormod Volden attachment added RelatedPackageVersions.txt http://launchpadlibrarian.net/44692545/RelatedPackageVersions.txt
2010-04-18 14:13:48 Tormod Volden affects xorg (Ubuntu) linux (Ubuntu)
2010-04-18 14:15:09 Tormod Volden summary gem objects not deallocated [KMS] gem objects not deallocated
2010-04-20 00:39:39 Bryce Harrington nominated for series Ubuntu Lucid
2010-04-20 00:39:39 Bryce Harrington bug task added linux (Ubuntu Lucid)
2010-04-20 00:40:09 Bryce Harrington linux (Ubuntu Lucid): importance Undecided Critical
2010-04-20 08:49:34 Tormod Volden bug watch added http://bugs.freedesktop.org/show_bug.cgi?id=26394
2010-04-20 10:13:55 William Grant affects linux (Ubuntu Lucid) xorg-server (Ubuntu Lucid)
2010-04-20 15:30:27 Vish xorg-server (Ubuntu Lucid): status New Confirmed
2010-04-21 22:22:33 Bryce Harrington description Binary package hint: xorg There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss 1020|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes: awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: xorg system: distro: Ubuntu codename: lucid architecture: i686 kernel: 2.6.34-999-generic [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented, and the issue believed fixed, but as further testing and analysis has been done it's come to light that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss 1020|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic
2010-04-21 22:29:30 Bryce Harrington description [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented, and the issue believed fixed, but as further testing and analysis has been done it's come to light that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss 1020|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss 1020|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic
2010-04-21 22:47:01 Bryce Harrington description [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss 1020|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff, and so Ubuntu took them in order to remain in sync with Debian. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Distros that don't include support for Clutter obviously won't see the bugs. Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss 1020|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic
2010-04-21 22:48:04 Bryce Harrington description [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff, and so Ubuntu took them in order to remain in sync with Debian. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Distros that don't include support for Clutter obviously won't see the bugs. Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss 1020|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss $(pidof X)|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic
2010-04-21 22:50:03 Kees Cook description [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps ocomm,vsz,rss $(pidof X)|grep X`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff, and so Ubuntu took them in order to remain in sync with Debian. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Distros that don't include support for Clutter obviously won't see the bugs. Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps --noheaders ocomm,vsz,rss ($pidof X)`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic
2010-04-22 10:55:37 Benjamin Séguret removed subscriber Benjamin Séguret
2010-04-22 13:10:40 Herakleitoszefesu removed subscriber Herakleitoszefesu
2010-04-22 16:46:26 Bilal Akhtar removed subscriber Bilal Akhtar
2010-04-22 18:22:10 Janne Uusitalo removed subscriber Janne Uusitalo
2010-04-22 20:43:21 Cassus removed subscriber Cassus
2010-04-22 21:31:22 Bryan Grim removed subscriber Bryan Grim
2010-04-22 21:52:55 Tormod Volden description [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff, and so Ubuntu took them in order to remain in sync with Debian. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Distros that don't include support for Clutter obviously won't see the bugs. Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps --noheaders ocomm,vsz,rss ($pidof X)`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic [Problem] Memory leak. Fix to glx 1.4 backport did not deallocate gem objects properly. [Background] Red Hat backported glx 1.3 and 1.4 support from xserver 1.8. These patches were taken by Debian as patches 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff, and so Ubuntu took them in order to remain in sync with Debian. Other distros using xserver 1.7 have likewise adopted these backports. Subsequent testing by Ubuntu identified an xserver crash that occurs with these patches enabled when closing Clutter apps. A partial fix was implemented in Ubuntu based on upstream work, and the issue believed solved, but further testing has shown that a slow memory leak is present, causing issues such as described below, which can result in system instability after a day or two of uptime (depending on memory quantity and usage). Distros that don't include support for Clutter obviously won't see the bugs. Following these findings, Debian has dropped the glx patches. Ubuntu is evaluating fixing the patches vs. following Debian's approach, being mindful of any userspace apps that may have come to depend on glx 1.3/1.4 functionality. [Original Report] There has been some buzz the last days about excessive swapping and OOM conditions. It can seem like the kernel memory use is increasing since the user processes seem not to grow unusually. /sys/kernel/debug/dri/0/gem_objects shows that the GEM object bytes number is increasing. One way to reproduce, is this: $ for t in `seq 1 10`; do eog /usr/share/backgrounds ; echo `grep "object bytes" /sys/kernel/debug/dri/0/gem_objects` `ps --noheaders ocomm,vsz,rss $(pidof X)`; done 142376960 object bytes Xorg 25812 15372 145907712 object bytes Xorg 25812 15372 150458368 object bytes Xorg 25812 15372 154816512 object bytes Xorg 25812 15372 159244288 object bytes Xorg 25812 15372 163721216 object bytes Xorg 25812 15372 168148992 object bytes Xorg 25812 15372 172699648 object bytes Xorg 25812 15372 177152000 object bytes Xorg 25812 15372 181530624 object bytes Xorg 25812 15372 It shows that the Xorg process is not growing, but gem objects are. Similarly counting and summing objects show there are gem objects adding up (with refcount 2) but not disappearing again when the application closes:  awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names These issues have been seen on intel and ati, with the lucid kernel as well as the mainline 2.6.34 snapshot. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: xorg 1:7.5+5ubuntu1 Uname: Linux 2.6.34-999-generic i686 Architecture: i386 Date: Sun Apr 18 15:59:21 2010 ProcEnviron:  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: xorg system:  distro: Ubuntu  codename: lucid  architecture: i686  kernel: 2.6.34-999-generic
2010-04-22 23:40:17 Herakleitoszefesu removed subscriber Herakleitoszefesu
2010-04-23 00:51:52 Robert Hooker xorg-server (Ubuntu Lucid): status Confirmed Fix Committed
2010-04-23 06:54:50 Tomáš Myšík xorg-server (Ubuntu Lucid): status Fix Committed Fix Released
2010-04-23 06:54:59 Tomáš Myšík xorg-server (Ubuntu Lucid): status Fix Released Fix Committed
2010-04-23 07:40:50 Andreas Schildbach removed subscriber Andreas Schildbach
2010-04-23 10:33:35 fgh xorg-server (Ubuntu Lucid): status Fix Committed Fix Released
2010-04-23 10:33:45 fgh xorg-server (Ubuntu Lucid): status Fix Released Fix Committed
2010-04-23 14:39:35 Paweł Nadolski removed subscriber Paweł Nadolski
2010-04-23 14:40:19 Oibaf removed subscriber Fabio Pedretti
2010-04-23 15:29:46 djchandler removed subscriber djchandler
2010-04-23 18:58:55 Benjamin Kraus removed subscriber Benjamin Kraus
2010-04-24 03:17:11 Robert Hooker xorg-server (Ubuntu Lucid): status Fix Committed Fix Released
2010-04-24 04:28:21 fgh xorg-server (Ubuntu Lucid): status Fix Released Fix Committed
2010-04-24 04:37:09 Robert Hooker xorg-server (Ubuntu Lucid): status Fix Committed Fix Released
2010-04-24 06:02:52 daniele80 removed subscriber daniele80
2010-04-24 06:49:12 Waldemar Brodkorb bug added subscriber LVM
2010-04-24 07:46:11 Mingming Ren removed subscriber Mingming
2010-04-24 11:06:02 Dudraug removed subscriber Dudraug
2010-04-25 15:22:08 Diego F. Rodríguez xorg-server (Ubuntu Lucid): status Fix Released Fix Committed
2010-04-25 15:22:23 Diego F. Rodríguez xorg-server (Ubuntu Lucid): status Fix Committed Fix Released
2010-04-26 01:48:10 Ding Zhou removed subscriber TualatriX
2010-04-26 04:52:39 James King xorg-server (Ubuntu Lucid): status Fix Released Fix Committed
2010-04-26 04:52:47 James King xorg-server (Ubuntu Lucid): status Fix Committed Fix Released
2010-04-26 15:06:52 Nicolás Abel Carbone removed subscriber Nicolás Abel Carbone
2010-04-27 15:27:21 Dak Ralter xorg-server (Ubuntu Lucid): status Fix Released In Progress
2010-04-27 15:27:27 Dak Ralter xorg-server (Ubuntu Lucid): status In Progress Fix Released
2010-04-27 18:11:28 Bane removed subscriber Bane
2010-04-28 06:10:38 Cat xorg-server (Ubuntu Lucid): status Fix Released Fix Committed
2010-04-28 06:10:53 Cat xorg-server (Ubuntu Lucid): status Fix Committed Fix Released
2010-05-02 00:56:19 Busby removed subscriber Busby
2010-05-02 19:01:19 Michał Gołębiowski-Owczarek removed subscriber Michał Gołębiowski
2010-05-04 08:04:08 Jakob Schiøtz removed subscriber Jakob Schiøtz
2010-05-17 16:34:22 Timo Lotila removed subscriber Timo Lotila
2010-09-17 21:40:06 Matt bug added subscriber Matt
2010-09-18 18:04:49 Tomáš Myšík removed subscriber Tomáš Myšík
2010-09-27 12:07:37 Walabom bug added subscriber Walabom
2011-02-05 19:06:35 Sam Rog removed subscriber Sam Rog
2012-04-19 22:13:58 Nicolas Delvaux removed subscriber Nicolas Delvaux