Bug#326956: xserver-xorg: Memory leak
Hi everyone, I wish to add some information about this issue, I'm using Testing on a Tyan S2460 with 2 GB memory and a nvidia Geforce4 MX440/64 MB, 2.6.18, official Xorg server from testing and I encounter very high leaks with nvidia driver 1.0.9639-1 (nvidia-glx-legacy-96xx package from unstable). So I used the standard/open source nv driver and encounter the same issue, but leak grows slower. I use gdm and Xfce4 which could be linked to the issue. After about more than 3d uptime, Xorg use now 12.30 % memory (12.78 % now after just 4 to 5 hours). With nvidia driver, after 4d uptime, it was about 35 % memory. I don't open more window or workspace, and memory consumption always grows while I'm not behind the computer, with a mere blank screensaver. Some memory seems to be never freed whatever I close as many windows/programs as I want. I jusy have one background image which never change. As some people talk about this here: http://ubuntuforums.org/showthread.php?t=440038 . and here: http://forums.gentoo.org/viewtopic-t-537634-postdays-0-postorder-asc-highlight-xorg+memory+leak-start-75.html It seems than XopenDisplay/XCloseDisplay sequence is potentially, and partially, responsible for the leak. Note than xrestop don't shows so much "unknow" identifier in my case. (This bug is of course for xserver-xorg-core package) Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326956: xserver-xorg: Memory leak
On Thu, May 31, 2007 at 08:17:21PM +0200, Brice Goglin wrote: > Hi, > > About 2 years ago, you reported (or replied to) a bug in the Debian BTS > regarding a memory leak in the X server. Did any of you guys reproduce > this problem recently? With Xorg/Etch? With latest xserver-xorg-core in > unstable? If not, I will close this bug in the next weeks. > > Thanks, > Brice I am currently using Ubuntu Feisty. This particular case of memory leaking does not occur now. Closing the bug sounds reasonable to me. -- Siep Kroonenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326956: xserver-xorg: Memory leak
Hi, About 2 years ago, you reported (or replied to) a bug in the Debian BTS regarding a memory leak in the X server. Did any of you guys reproduce this problem recently? With Xorg/Etch? With latest xserver-xorg-core in unstable? If not, I will close this bug in the next weeks. Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326956: xserver-xorg: Memory leak
On Thu, Sep 08, 2005 at 06:13:49PM +0200, David Mart?nez Moreno wrote: > El miércoles, 7 de septiembre de 2005 19:27, Michel Dänzer escribió: > > > Such behavior would be acceptable if X.org forgot old background > > > images. But it doesn't. Try to successively load a series of > > > background images, e.g. from the KDE wallpaper collection, and the > > > memory occupied by Xorg will keep growing. > > > > First of all, verify using something like xrestop that it's not actually > > a client leaking references to the wallpaper pixmaps. > > > > Even if that's ruled out, freeing memory that was allocated from the > > heap can't always be returned to the system immediately because the heap > > can only shrink down to the highest allocation still in use. If that's > > the case, it should still be able to re-use a gap sometimes, especially > > when you switch to a smaller wallpaper, in which case the memory usage > > reported for the X server shouldn't increase. > > > > I'm curious as to which of these might apply to your situation, if any. > > Hello, Siep. I have been testing with xrestop and Michel is right. My > machine > runs KDE 3.4.2 and X.Org 6.8.2.dfsg.1-6, and I cannot see any increment in > the memory usage in X. When I use a background, I see KDE Desktop process > going up in the comsumption list, but it does not surpass 5917 KB in any > case, even when I changed about twenty times my background desktop image. > > I even saw Xorg process in a common 'top' with 115 MB of "resident > memory". > Another round of image switching did not changed Xorg's memory, until my > default setting: no background image. In this moment, Xorg even give me back > 5 MB of memory, falling to 110 MB. > > Is this true for you? If so, I would like to close this bug. > > Best regards, > > > Ender. I believe there is still a memory leak. After startup, on my system Xorg takes up about 10mb of memory. This increases to 30mb and more after one or two days even after closing all applications. However, today memory use could no longer be increased without limit just by loading different background images: the memory sometimes goes up and sometimes down and doesn't go up further than about 3mb total amount. I don't know what caused the change. Now that I no longer have a simple way to trigger a memory leak you are probably right to close this bug. xserver-xorg is version 6.8.2.dfsg.1-5, and the window manager a hand-compiled fvwm 2.4.18. Regards, -- Siep Kroonenberg
Bug#326956: xserver-xorg: Memory leak
El miércoles, 7 de septiembre de 2005 19:27, Michel Dänzer escribió: > > Such behavior would be acceptable if X.org forgot old background > > images. But it doesn't. Try to successively load a series of > > background images, e.g. from the KDE wallpaper collection, and the > > memory occupied by Xorg will keep growing. > > First of all, verify using something like xrestop that it's not actually > a client leaking references to the wallpaper pixmaps. > > Even if that's ruled out, freeing memory that was allocated from the > heap can't always be returned to the system immediately because the heap > can only shrink down to the highest allocation still in use. If that's > the case, it should still be able to re-use a gap sometimes, especially > when you switch to a smaller wallpaper, in which case the memory usage > reported for the X server shouldn't increase. > > I'm curious as to which of these might apply to your situation, if any. Hello, Siep. I have been testing with xrestop and Michel is right. My machine runs KDE 3.4.2 and X.Org 6.8.2.dfsg.1-6, and I cannot see any increment in the memory usage in X. When I use a background, I see KDE Desktop process going up in the comsumption list, but it does not surpass 5917 KB in any case, even when I changed about twenty times my background desktop image. I even saw Xorg process in a common 'top' with 115 MB of "resident memory". Another round of image switching did not changed Xorg's memory, until my default setting: no background image. In this moment, Xorg even give me back 5 MB of memory, falling to 110 MB. Is this true for you? If so, I would like to close this bug. Best regards, Ender. -- So much to do, so little time... -- Joker (Batman). -- Debian developer pgpnuNXR7A8uu.pgp Description: PGP signature
Bug#326956: xserver-xorg: Memory leak
On Wed, 2005-09-07 at 14:43 +0200, Siep Kroonenberg wrote: > On Wed, Sep 07, 2005 at 11:57:01AM +0200, David Mart?nez Moreno wrote: > > El martes, 6 de septiembre de 2005 23:17, Siep Kroonenberg escribió: > > > Loading a new background image on the root window usually increases > > > the amount of memory taken up by Xorg by 2 or 3 mb, going by the RES > > > column of top. [...] > Such behavior would be acceptable if X.org forgot old background > images. But it doesn't. Try to successively load a series of > background images, e.g. from the KDE wallpaper collection, and the > memory occupied by Xorg will keep growing. First of all, verify using something like xrestop that it's not actually a client leaking references to the wallpaper pixmaps. Even if that's ruled out, freeing memory that was allocated from the heap can't always be returned to the system immediately because the heap can only shrink down to the highest allocation still in use. If that's the case, it should still be able to re-use a gap sometimes, especially when you switch to a smaller wallpaper, in which case the memory usage reported for the X server shouldn't increase. I'm curious as to which of these might apply to your situation, if any. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#326956: xserver-xorg: Memory leak
El Miércoles, 7 de Septiembre de 2005 14:43, Siep Kroonenberg escribió: > On Wed, Sep 07, 2005 at 11:57:01AM +0200, David Mart?nez Moreno wrote: > > El martes, 6 de septiembre de 2005 23:17, Siep Kroonenberg escribió: > > > Loading a new background image on the root window usually increases > > > the amount of memory taken up by Xorg by 2 or 3 mb, going by the RES > > > column of top. > > > > I suppose that this is not a bug, but that X.Org is translating the > > image to a bitmap, thus growing itself in size. I made this test: [...] > Such behavior would be acceptable if X.org forgot old background > images. But it doesn't. Try to successively load a series of > background images, e.g. from the KDE wallpaper collection, and the > memory occupied by Xorg will keep growing. Ah, all right. That information was not present (or at least, not so clear) in your first report. I will take a deeper look. Best regards, Ender. -- Network engineer Debian Developer pgpkEaXFROM6J.pgp Description: PGP signature
Bug#326956: xserver-xorg: Memory leak
On Wed, Sep 07, 2005 at 11:57:01AM +0200, David Mart?nez Moreno wrote: > El martes, 6 de septiembre de 2005 23:17, Siep Kroonenberg escribió: > > Loading a new background image on the root window usually increases > > the amount of memory taken up by Xorg by 2 or 3 mb, going by the RES > > column of top. > > I suppose that this is not a bug, but that X.Org is translating the > image to > a bitmap, thus growing itself in size. I made this test: > > I had this JPEG image: > > -rw--- 1 ender ender 132873 sep 7 11:49 orbes.jpg > > Then converted with Gimp to a bitmap, and: > > -rw-r--r-- 1 ender ender 2359350 sep 7 11:51 orbes.bmp > -rw--- 1 ender ender 132873 sep 7 11:49 orbes.jpg > > It was a 1024x768 image. It resulted between 2 and 3 MB. > > Could anybody from debian-x confirm my suspicions that this is normal > behavior before closing this bug? > > Best regards, > > > Ender. Such behavior would be acceptable if X.org forgot old background images. But it doesn't. Try to successively load a series of background images, e.g. from the KDE wallpaper collection, and the memory occupied by Xorg will keep growing. -- Siep Kroonenberg
Bug#326956: xserver-xorg: Memory leak
El martes, 6 de septiembre de 2005 23:17, Siep Kroonenberg escribió: > Loading a new background image on the root window usually increases > the amount of memory taken up by Xorg by 2 or 3 mb, going by the RES > column of top. I suppose that this is not a bug, but that X.Org is translating the image to a bitmap, thus growing itself in size. I made this test: I had this JPEG image: -rw--- 1 ender ender 132873 sep 7 11:49 orbes.jpg Then converted with Gimp to a bitmap, and: -rw-r--r-- 1 ender ender 2359350 sep 7 11:51 orbes.bmp -rw--- 1 ender ender 132873 sep 7 11:49 orbes.jpg It was a 1024x768 image. It resulted between 2 and 3 MB. Could anybody from debian-x confirm my suspicions that this is normal behavior before closing this bug? Best regards, Ender. -- Network engineer Debian Developer pgpDQbFp3Fm6Y.pgp Description: PGP signature
Bug#326956: xserver-xorg: Memory leak
Package: xserver-xorg Version: 6.8.2.dfsg.1-5 Severity: normal Loading a new background image on the root window usually increases the amount of memory taken up by Xorg by 2 or 3 mb, going by the RES column of top. -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 xserver-xorg /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 17 Jul 24 22:21 /etc/X11/X -> /usr/bin/X11/Xorg -rwxr-xr-x 1 root root 2167168 Aug 11 15:48 /usr/bin/X11/Xorg Contents of /var/lib/xfree86/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: :00:10.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02) /var/lib/xfree86/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 4028 Aug 11 13:34 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands: # # cp /etc/X11/xorg.conf /etc/X11/xorg.conf.custom # sudo sh -c 'md5sum /etc/X11/xorg.conf >/var/lib/xfree86/xorg.conf.md5sum' # sudo dpkg-reconfigure xserver-xorg Section "Files" # FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath "/usr/local/lib/fonts/win/:unscaled" FontPath"/usr/lib/X11/fonts/misc:unscaled" # FontPath "/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" #FontPath "/usr/lib/X11/fonts/Type1" #FontPath "/usr/lib/X11/fonts/CID" FontPath"/usr/local/lib/fonts/Type1" FontPath"/usr/local/lib/fonts/math-ttf/cmtex-ttf" FontPath"/usr/local/lib/fonts/math-ttf/mathematica-ttf" FontPath"/usr/local/lib/fonts/TrueType" FontPath"/usr/local/lib/fonts/jre" # FontPath"/usr/lib/X11/fonts/cyrillic" # FontPath"/usr/lib/X11/fonts/100dpi" # FontPath"/usr/lib/X11/fonts/75dpi" # paths to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"type1" Load"vbe" # Load"wacom" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbLayout" "us" Option "XkbRules" "xorg" Option "XkbModel" "macintosh" EndSection # Option "XkbRules" "xfree86" # Option "XkbModel" "pc104" Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Driver "wacom" Identifier "WacomMouse" Option "Device" "/dev/wacom" Option "Mode" "Relative" # Option "Threshold" "6" Option "Type" "cursor" Option "USB" "on" EndSection Section "InputDevice" Driver "wacom" Identifier "Wacom" Option "Device" "/dev/wacom" Option "Mode" "Absolute" # Option "Threshold" "6" Option "Type" "stylus" Option "USB" "on" EndSection Section "Device" Identifier "ati" Driver "ati" BusID "PCI:0:16:0" Option "UseFBDev" "true" EndSection Section "Monitor" Identifier "laptop" Option "DPMS" HorizSync 30-57 VertRefresh 43-72 EndSection Section "Screen" Identifier "Default Screen" Device "ati" Monitor "laptop" DefaultDepth24 SubSection "Display" Depth 1 Modes "1024x768" EndSubSection
