FS#13662 - xorg-server 1.6 massive memleak

Attached to Project: Arch Linux
Opened by Peter Kraus (PetoKraus) - Wednesday, 04 March 2009, 16:36 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 14 April 2009, 21:56 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
I'm running Xorg-server 1.6.0 from testing, with xf86-video-ati driver and hotplugging enabled. Since the update, the xorg gets MASSIVE memory leaks for some strange reason; since yesterday evening (that's about 18 hours) it consumed up 51.2% of my system memory, over 1189MB. This has not happened before.

Additional info:
xorg-server 1.6.0-1
xf86-video-ati 6.11.0-1

card: ATI Mobility Radeon X1400
xorg.conf: http://www.irc.gjh.sk/pastebin/768 (I'm using hotplugging, hence it's quite short)
Xorg.0.log: http://www.irc.gjh.sk/pastebin/769


Steps to reproduce:
1) upgrade to freshest testing xorg-server
2) wait few hours
3) observe memory leak
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Tuesday, 14 April 2009, 21:56 GMT
Reason for closing:  Not a bug
Comment by Jan de Groot (JGC) - Wednesday, 04 March 2009, 17:56 GMT
Do you use a compositing manager, or is this just with a plain 2D desktop?
Comment by Peter Kraus (PetoKraus) - Wednesday, 04 March 2009, 17:58 GMT
It's plain 2D desktop, using Enlightenment E17; it was working perfectly before.
Comment by Jan de Groot (JGC) - Wednesday, 04 March 2009, 18:17 GMT
What are the values you get for VIRT, RES and SHR memory in top for the Xorg process?
Comment by Jan de Groot (JGC) - Wednesday, 04 March 2009, 18:21 GMT
Besides Xorg being the possible problem, could you download xrestop from http://www.freedesktop.org/wiki/Software/xrestop and run it?

just unpack the tarball, change into the directory, run:
./configure
make
./xrestop

It will show you what application has which memory allocated inside X. Some applications are known to cause memory leaks because they allocate pixmaps all over the place while never releasing them. This can be a bug in both xorg-server or e17 for example.
Comment by Peter Kraus (PetoKraus) - Wednesday, 04 March 2009, 18:33 GMT
ps axu output:
root 24338 4.6 4.7 171784 96732 tty7 Ss+ 16:38 5:07 /usr/bin/X -nolisten tcp

top output:
24338 root 20 0 488m 94m 10m S 6 4.7 5:07.49 X

This is after 2 hours of running; I'll post the values later on to get the effect. I obviously restarted the X as I filed the bug, working with 340MB "free" RAM was not fun :)

For the xrestop, gimme a while.
Comment by Peter Kraus (PetoKraus) - Wednesday, 04 March 2009, 18:39 GMT
2 Hours of use:
Top: http://www.irc.gjh.sk/pastebin/772
Xrestop: http://www.irc.gjh.sk/pastebin/770

I will get back home at about 22.00, which is in roughly 4 hours; I'll update the values then.
Comment by Andreas Radke (AndyRTR) - Wednesday, 04 March 2009, 20:06 GMT
4732 root 20 0 495m 75m 16m S 7 4.0 25:36.28 Xorg

for me [andyrtr@laptop64 ~]$ uptime
21:06:30 up 5:36, 2 users, load average: 0.14, 0.28, 0.32

no noticable difference to last release. (Xfce here, X300m card)
Comment by Jan de Groot (JGC) - Wednesday, 04 March 2009, 22:48 GMT
Found a resource leak on my system: gnome-screensaver eats 6MB everytime you lock and unlock the screen. This is using the intel driver with UXA though.
Comment by Peter Kraus (PetoKraus) - Wednesday, 04 March 2009, 23:47 GMT
top: http://www.irc.gjh.sk/pastebin/773
xrestop: http://www.irc.gjh.sk/pastebin/774
The X is up for about 7 hours.
Comment by Jan de Groot (JGC) - Thursday, 05 March 2009, 10:30 GMT
Seems you're running an OpenGL game there. OpenGL games don't allocate memory via X resources. On shared memory systems I think the used graphics memory is added to the Xorg process.
Comment by Peter Kraus (PetoKraus) - Thursday, 05 March 2009, 10:37 GMT
Yes, I have been, but even after I closed the game, 300MB memory (from Urban Terror) was freed, but the memory allocated to X remained the same, and in the morning, after 15 hours of X uptime, the memory for X only totalled up on 931M, with similar xrestop values.
Comment by Jan de Groot (JGC) - Thursday, 05 March 2009, 10:47 GMT
It's possible that something in the 3D subsystem doesn't give back the allocated texture memory. I think this is a bug in the ati dri drivers. Did the xrestop values increase after running X for 15 hours?
Comment by David K. (dcrabs) - Thursday, 05 March 2009, 11:15 GMT
I've got the same here with intel drivers from testing; X memory increases steadily. It only happens when 3d-effects are enabled. xrestop values do not increase noticeable. Disabling KDE4.2 desktop effects stops it.
Comment by Peter Kraus (PetoKraus) - Thursday, 05 March 2009, 18:18 GMT
Right, this is me after 8-ish hours of running. The X have 613MB, and no OpenGL application/3D app were running (in fact, the only apps I use are grellm, xchat, pidgin, firefox, liferea, sunbird and quodlibet - no 3D/OGL afaik). The second, i686 machine running (the new from testing) nouveau driver does not have this leak/problems.

Shall I bug ati driver upstream with this?
Comment by Peter Kraus (PetoKraus) - Friday, 06 March 2009, 00:23 GMT
Right, at the midnight, the memleak reached whooping 1200MB, without running anything GPU heavy (the machine literally remained idle for 3/4 of the time). I'll try to trace down this problem by temporarily switching to the radeonhd driver, we'll see whether that leaks as well.
Comment by Peter Kraus (PetoKraus) - Friday, 06 March 2009, 09:36 GMT
Alrighty, 9:30 in the morning, with xf86-video-radeonhd 1.2.4-2:
top: http://www.irc.gjh.sk/pastebin/776
xrestop -b -m 1: http://www.irc.gjh.sk/pastebin/777

That's right, 667MB consumed after 9 hours with different driver, I guess it's not caused by the driver, but by xorg itself. Should I try downgrading just to be sure?
Comment by Jan de Groot (JGC) - Friday, 06 March 2009, 09:42 GMT
Remember that radeonhd and ati share a lot of code. You might try the vesa driver for a while, though it's dead slow and possibly doesn't even support your native display resolution.

Do you use suspend/resume btw?
Comment by Peter Kraus (PetoKraus) - Friday, 06 March 2009, 09:53 GMT
No I didn't, the only thing I have is display blanking, but I doubt that's the thing which causes it. I'm trying to ask in #xorg for help. The vesa thing seems to be a good idea; I'll get back here in few hours...
Comment by Jan de Groot (JGC) - Friday, 06 March 2009, 10:06 GMT
Can you also run pmap on the PID of the Xorg process?

BTW, you might want to attach your logs instead of putting them on a pastebin. The pastebin postings expire after a while, making this bugreport worthless after a while.
Comment by Peter Kraus (PetoKraus) - Friday, 06 March 2009, 10:15 GMT
These don't expire, it's my friends pastebin.

I can't seem to get vesa running on the display, the thing fails with:

(EE) VESA(0): Driver can't support depth 24
(II) UnloadModule: "vesa"
(II) UnloadModule: "int10"
(II) Unloading /usr/lib/xorg/modules//libint10.so
(II) UnloadModule: "vbe"
(II) Unloading /usr/lib/xorg/modules//libvbe.so
(EE) Screen(s) found, but none have a usable configuration.

The pmap of freshly restarted X is attached, I'll post one later when I get back home.
   pmap (9.5 KiB)
Comment by Peter Kraus (PetoKraus) - Friday, 06 March 2009, 12:49 GMT
Right, 2:30 into the day and it's 224MB; I'll attach the logs; this time, there is a clue, i guess most of the memory is consumed by drm/dri...
   topfile (3 KiB)
   pmap (9.6 KiB)
   xrestoplog (5.8 KiB)
Comment by Jan de Groot (JGC) - Friday, 06 March 2009, 13:53 GMT
You might want to disable AIGLX. I don't know if it's the AIGLX interface itself that is leaking memory here, or the whole DRI infrastructure involving r300_dri is affected here.
Comment by Jan de Groot (JGC) - Friday, 06 March 2009, 23:32 GMT
I've tracked the intel memory leak down to two bugs involving VT switching, which are both fixed in git. Another issue is the unlimited bo cache which is allocated by the driver. Disabling it, or even limiting it keeps memory usage on intel low.

For the ATI driver, no memory reservations are done by the 2D driver. The 3D drivers seem to be doing this. I haven't found any references to memleaks yet, so this is much harder to track down.
Comment by Peter Kraus (PetoKraus) - Saturday, 07 March 2009, 00:10 GMT
I'm testing now with AIGLX disabled. If the bug persists (which I think does, but I'm not sure yet), I am going to try git-compiled ati driver, and I will let you know. The guys at #xorg @ freenode didn't look into it yet, I guess I might try to mail the ati-devel mailinglist. Tomorrow.
Comment by David K. (dcrabs) - Saturday, 07 March 2009, 09:18 GMT
Thanks, that is good news for the intel driver. I tried the git-version but it doesn't start here. Maybe it is too early. Any hints on disabling bo cache? I couldn't find anything about it.
Comment by Peter Kraus (PetoKraus) - Saturday, 07 March 2009, 22:21 GMT
Leaks with AIGLX disabled, at a slower rate though. Testing with yesterday's git version, from aur pkgbuild, compiled againist mesa 7.3. Will post results tomorrow.
Comment by David K. (dcrabs) - Sunday, 08 March 2009, 13:48 GMT
With latest intel drivers from testing, the memory leak still exists. Especially the expose-effect in KDE4.2 lets X increase its memory by up to 3MB every time!
Comment by Jan de Groot (JGC) - Sunday, 08 March 2009, 13:58 GMT
Please report intel issues in a different bugreport. This issue is about ati drivers, not intel.
Also remember that KDE itself could be leaking pixmaps here everytime. These don't show up in xrestop because they're 3D pixmaps.
Comment by Peter Kraus (PetoKraus) - Sunday, 08 March 2009, 20:26 GMT
The latest git xf86-video-ati does leak as well. I'm reverting back to [testing]. I see you've updated some of the packages (libdrm, mesa), so, maybe...
Comment by Jan de Groot (JGC) - Sunday, 08 March 2009, 21:03 GMT
Mesa only received a rebuild to add an extra dependency. All fixes done in libdrm are for intel only.
I think you should look into libgl, mesa and ati-dri for your memory leaks, as all memory allocation is done by the DRI drivers with xf86-video-ati/radeonhd. This will change when everything is switched to GEM.
Comment by Peter Kraus (PetoKraus) - Sunday, 08 March 2009, 21:58 GMT
Sent a message to ati devel mailing list. I'll keep it updated here.
Comment by Peter Kraus (PetoKraus) - Tuesday, 10 March 2009, 15:04 GMT
I was advised to revert back to the non-leaking version package by package.
Tried with xf86-video-ati 6.10.0, that memleaks as well. Trying with ati-dri 7.2 as well now; will get back here later.
Comment by Jan de Groot (JGC) - Tuesday, 10 March 2009, 15:10 GMT
Remember that ati-dri links against libdricore.so from libgl. To get it working, you might want to rebuild ati-dri without the mesa-shared patch.
Comment by Peter Kraus (PetoKraus) - Sunday, 22 March 2009, 01:43 GMT
Hello,
the problem seems to be with the xorg-server package, as the ati/mesa related things do not cause this. It's strange indeed. I'll try playing around with the compile options in the PKGBUILD, but due to the inherent nature of this problem, it's going to take loads of time.
Comment by Peter Kraus (PetoKraus) - Saturday, 11 April 2009, 11:02 GMT
OK, seems to not leak that much under Openbox; let's say it's E's problem.

Loading...