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 |
|
|
|