MASTER: memory leak

Using Kubuntu Gutsy on amd64, nvidia-glx-new package, 512MB RAM

It seems that firefox/flash is indeed the culprit. I've been trying to track down the cause of unresponsiveness in my system for days. First I figured it was Xgl, so I disabled it - but then the bug hit me again on plain Xorg. Finally found this bug report. Closed firefox, found that it left orphaned processes. Killed those off, now my system seems as responsive as ever. I am using a 32-bit browser in a chroot environment, if that helps.

i am using ubuntu gutsy, intel driver. after compiz is switched off and gdm restart performed, the situation is normal and stable.

i have this issue. closing firefox, and other desktop apps does not help. X remains 408MB (after starting at 80MB). almost all of this memory is private (not shared libraries etc.). I've tried using MOZ_DISABLE_IMAGE_OPTIMIZE, but it didn't seem to make a change.

xrestop does not show a lot of pixmap memory used (only 7.6MB total).

so x is taking a lot of memory, that isn't pixmaps memory

I'm trying the intrepid ubuntu and this issue appear then.
In gusty I din't have any problems. Since I upgraded, I have a huge memory consumption by Xorg. And slowly it increases reatching sometimes 150Mo.
If I disable compiz (and kill the serveur) then my Xorf memory stay around to 30Mo.

In both case firefox take too huge memory only with few tabs (120Mo with 3 tabs)
It's clearly visible. I want this problem solved so don't hesitate to ask me for more help.

    lspci:
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

    aptitude show xorg
Paquet : xserver-xorg
État: installé
Automatiquement installé: non
Version : 1:7.4~2ubuntu6

    aptitude show compiz
Paquet : compiz
État: installé
Automatiquement installé: non
Version : 1:0.7.8-0ubuntu1

Yup confirming here on three terminals. Restarting XORG ctrl-alt-backspace clears the memory and start the xorg clogging from new. Is a pain. Usually it takes about 24 hours for the system to become so unresponsive that I need to restart either the terminal or Xorg.

Somebody please explain this output from top:
15744 20 0 1029m 345m 32m S 12 17.2 33:11.88 firefox
22617 20 0 395m 243m 6944 S 10 12.1 27:47.82 Xorg
24251 20 0 592m 89m 23m S 6 4.5 13:38.97 plasma
28131 20 0 612m 81m 58m S 0 4.1 0:02.50 soffice.bin
28215 20 0 503m 80m 33m S 4 4.0 0:03.50 konqueror
20960 20 0 840m 80m 35m S 2 4.0 4:31.19 amarok

and xrestop:
xrestop - Display: :0
          Monitoring 45 clients. XErrors: 0
          Pixmaps: 58122K total, Other: 177K total, All: 58300K total

After quitting firefox (i'm writing this from konqueror), top:
22617 20 0 394m 243m 6696 S 3 12.1 27:57.58 Xorg
24251 20 0 592m 90m 23m S 3 4.5 13:44.09 plasma
28131 20 0 612m 81m 58m S 0 4.1 0:02.53 soffice.bin
28215 20 0 504m 80m 34m S 0 4.0 0:07.18 konqueror
20960 20 0 840m 80m 35m S 0 4.0 4:31.53 amarok

xrestop - Display: :0
          Monitoring 43 clients. XErrors: 0
          Pixmaps: 57079K total, Other: 146K total, All: 57225K total

Only 1MB got freed, Xorg is still eating up 243MB. BTW, my graphics card has "only" 128 MB, so it cannot be that memory shown as used by Xorg is actually memory from the graphics card.

Cheers!

BTW, I disabled compiz, fearing that it would be the cause, it turned out that it wasn't.

I really don't understand, how such a grave bug can go unfixed for such a long time, and is even marked as low. I have this problem since at least 4 versions of Ubuntu (kubuntu), and was hoping for a fix after each upgrade. Unfortunately in vain.

My xorg currently uses up
7142 root 20 0 1835m 1.3g 8416 S 8 44.1 537:48.47 Xorg
after 8 days of uptime (that's 1,3Gig, and it continues to grow until the machine becomes unusable because of swapping). Only solution: Reboot (WinXP sends his best regards).

xrestop shows:
xrestop - Display: :0
          Monitoring 39 clients. XErrors: 3
          Pixmaps: 141213K total, Other: 1856K total, All: 143070K total

My graphics card has 128MB (GeForce FX 5200), and I use Xinerama (2 monitors) with the nvidia driver.
ii nvidia-glx-new 169.12+2.6.24.15-23.55 NVIDIA binary XFree86 4.x/X.Org 'new' driver
ii nvidia-kernel-common 20051028+1ubuntu8 NVIDIA binary kernel module common files

Otherwise I'm still running stock kubuntu 8.04.
2.6.24-23-generic #1 SMP Thu Nov 27 18:44:42 UTC 2008 i686 GNU/Linux

I'd really appreciate, if some effort were put in fixing this painful bug.

Cheers,

Roland

Actually you don't have to reboot, just restart the X-server by quitting the session and hitting Alt-E in kdm or gdm login screen. But yes, the bug is still there. After switching to ubuntu (I just installed the packages) I still get the same behaviour.

>>>>> "Francisco" == Francisco <email address hidden> writes:

    Francisco> Actually you don't have to reboot, just restart the
    Francisco> X-server by quitting the session and hitting Alt-E in
    Francisco> kdm or gdm login screen. But yes, the bug is still
    Francisco> there. After switching to ubuntu (I just installed the
    Francisco> packages) I still get the same behaviour.

Sure I know. But loosing the X-Session on my workstation is just as
bad as a reboot.

Is anybody working on the problem? By the way: I don't have the issue
on my workstation at work. Here I am running a 64bit Kernel though
with a GeForce 7600 GS card.

    Francisco> -- MASTER: memory leak
    Francisco> https://bugs.launchpad.net/bugs/98783 You received this
    Francisco> bug notification because you are a direct subscriber of
    Francisco> the bug.

The problem is that the people that can work on the problem think that there
is no problem, since measuring memory use is not something easy, and any
badly written app (typically it was flashplayer, but I already tried
disabling it) can leak pixmem. So until somebody of us identify which is the
culprit, and it can be different for any of us, there's no way this is going
to be solved.

The fact is that now my X server is using ~300m and if I quit the session
(all X programs except gdm), it will still be using almost all that memory,
go figure.

Now, you say that with another graphics card you don't have the same
problem, maybe that is the root of all evil, are you using the same version
of the nvidia driver? Most reports have been with nVidia, and since some of
the reports are "false positives" it may well be a driver problem.

Comment #11 is a good summary of the situation. Currently, none of the comments on this bug provide sufficient information to do troubleshooting. Memory usage problems tend to be very hard to debug, especially when they cannot be reproduced independently.

For people using the -nvidia driver, you're almost entirely out of luck - the binary proprietary -nvidia driver replaces pretty large swaths of the xserver's internals with its own code, so debugging issues with that driver are almost always futile. If the bug is sufficiently well reported, it could be forwarded to -nvidia, but so far not enough has been provided.

>>>>> "Bryce" == Bryce Harrington <email address hidden> writes:

    Bryce> Comment #11 is a good summary of the situation. Currently,
    Bryce> none of the comments on this bug provide sufficient
    Bryce> information to do troubleshooting. Memory usage problems
    Bryce> tend to be very hard to debug, especially when they cannot
    Bryce> be reproduced independently.

Sure, I'm aware of that.

    Bryce> For people using the -nvidia driver, you're almost entirely
    Bryce> out of luck - the binary proprietary -nvidia driver
    Bryce> replaces pretty large swaths of the xserver's internals
    Bryce> with its own code, so debugging issues with that driver are
    Bryce> almost always futile. If the bug is sufficiently well
    Bryce> reported, it could be forwarded to -nvidia, but so far not
    Bryce> enough has been provided.

What additional information do you require?

Maybe nouveau will be an alternative in 9.04.

I have the same problem on my laptop running 8.10 which has a standard intel graphics card, and have had this problem ever since 7.04 (didn't use ubuntu before then).

Like Francisco, my Xrestop also looks fairly 'normal', and closing firefox doesn't change more than at most a couple of meg of ram.

Its a pretty annoying bug because it forces me to restart ubuntu every day, or wave goodbye to a couple hundred meg of ram.

Anything I can do to mitigate the problem / any command to run that can aid in debugging the problem?

Cheers, and keep up the good work, really enjoying my switch to ubuntu so far! :-)

Well, that rules out nVidia binaries as a source of the problem, at least
Pete's problem.

On Sun, Jan 18, 2009 at 5:13 PM, Pete <email address hidden> wrote:

> I have the same problem on my laptop running 8.10 which has a standard
> intel graphics card, and have had this problem ever since 7.04 (didn't
> use ubuntu before then).
>
> Like Francisco, my Xrestop also looks fairly 'normal', and closing
> firefox doesn't change more than at most a couple of meg of ram.
>
> Its a pretty annoying bug because it forces me to restart ubuntu every
> day, or wave goodbye to a couple hundred meg of ram.
>
> Anything I can do to mitigate the problem / any command to run that can
> aid in debugging the problem?
>
> Cheers, and keep up the good work, really enjoying my switch to ubuntu
> so far! :-)
>
> --
> MASTER: memory leak
> https://bugs.launchpad.net/bugs/98783
> You received this bug notification because you are a direct subscriber
> of the bug.
>

while knowing very little about X, I think in general, it would be nice if pixmaps were associated with the process that requested them (maybe by just having the process associate a constant label with the pixmaps it uses). then it would be possible to write a utility named pixmaptop and also to cleanup pixmaps (even if not automatically, at least manually), and also to have something like sar to show usage trends (memory leaks)

Another data point. I'm having the same overall issue using the radeonhd driver on my laptop, so there may or may not really be an issue with leaks in the nvidia driver. It sure seems to be related to firefox and flash content as the memory usage of the xorg process ramps up when I run firefox (1.5.x thru 3.0.5) and ramps up exponentially faster for pages that have flash content. Killing/quiting firefox frees up a lot of memory, but not from Xorg's overall total. It has behaved like this (for me) for the past couple of years. Only reason it's not a big deal for me is I'm constantly having suspend/resume issues since the 7.10 release, so uptime never exceeds a couple of weeks anymore. :(

>>>>> "Michael" == Michael Milligan <email address hidden> writes:

    Michael> Another data point. I'm having the same overall issue
    Michael> using the radeonhd driver on my laptop, so there may or
    Michael> may not really be an issue with leaks in the nvidia
    Michael> driver. It sure seems to be related to firefox and flash
    Michael> content as the memory usage of the xorg process ramps up
    Michael> when I run firefox (1.5.x thru 3.0.5) and ramps up
    Michael> exponentially faster for pages that have flash content.
    Michael> Killing/quiting firefox frees up a lot of memory, but not
    Michael> from Xorg's overall total. It has behaved like this (for
    Michael> me) for the past couple of years. Only reason it's not a
    Michael> big deal for me is I'm constantly having suspend/resume
    Michael> issues since the 7.10 release, so uptime never exceeds a
    Michael> couple of weeks anymore. :(

Hmm, thinking about this makes it pretty clear to me know. It really
must be firefox + flash. My firefox on x86 recently also acquired
about 1.5GB of RAM with the X server running at more than 2GB. Killing
the firefox instance also released quite a lot of RAM from the X
server. But more importantly: As reported earlier, I don't have the
problem on my amd64 desktop at work. And guess what! I don't have a
flash plugin running for my firefox there.

So please debugger folks. Test along these lines, and I am almost
certain you will find the real cause of this.

Roland

hm, i'm not so shure its flash.

I just ran suspendtests for jaunty amd64 on my t61 intel GM965/GL960 iwl4965, and in just a uptime of 1hour40, thats how top looks:

top - 11:33:47 up 1:39, 2 users, load average: 0.12, 0.24, 4.16
Tasks: 141 total, 3 running, 138 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.5%us, 4.9%sy, 0.0%ni, 87.1%id, 0.0%wa, 0.5%hi, 0.0%si, 0.0%st
Mem: 2009004k total, 1556044k used, 452960k free, 55956k buffers
Swap: 3903752k total, 388372k used, 3515380k free, 299620k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 2734 root 20 0 2361m 750m 105m R 17 38.2 4:31.65 Xorg
 3492 karlrt 20 0 632m 186m 19m S 4 9.5 1:52.26 firefox
 3281 karlrt 20 0 253m 16m 6908 S 1 0.8 0:17.06 compiz.real

38 % of my 2GB memory. I only have firefox open, and didnt use flash the whole uptime (just have been on launchpad pages with firefox)

So for me, it has nothing to do with proprietary drivers or software, i only used OS to use my memory that much. I would really like to debug this, but just dont know how i can help further?

I just found a way to easily increase memory consumption for X.org. This works at least on two machines, a desktop and a notebook, with intrepid and KDE 4.2.2. Both machines have a NVidia card (Quatro NVS-290 and GeForce Go 7400) and I tried it with both the nv and the newest nvidia driver with the same result.

Open okular with a very big file. Now you can see memory usage of X rising just by scrolling through the document. After going through 200-300 pages X needs around 1GB of memory.
Sometimes the memory got released after closing okular but most of the time the amount of memory was just lost.

I have tried this with a big djvu and a different pdf file with the same result. Using acroread for the pdf file, no increase in memory consumption can be observed.

Hopefully this very annoying bug can be solved soon...

why is it a wont fix?

On Wed, Apr 08, 2009 at 05:32:08PM -0000, karlrt wrote:
> why is it a wont fix?

Because it's already filed against xorg-server. It's redundant to file
it against xorg, too.

The X server was eating around 500MB, almost half my system memory. I was able to reduce that by about half by killing and restarting firefox, killing okular, killing oocalc, changing system -> preferences -> appearance -> no effects, killing compiz-decorator.

As to the theory that it isn't a memory leak but instead just X holding pixmaps, I have some numbers that disagree. Notice the huge discrepancy between total memory reported by top and total memory reported by xrestop. Sure, I got rid of a lot of pixmaps by killing some applications. But the xserver is only able to account for 17MB of 258MB of usage.

 top:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 4199 root 20 0 1231m 266m 8948 S 1.3 27.0 744:38.61 Xorg

xrestop
xrestop - Display: :0.0
          Monitoring 54 clients. XErrors: 0
          Pixmaps: 18688K total, Other: 308K total, All: 18997K total

res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
2400000 361 361 1 318 223 5371K 23K 5395K 14185 Downloads
0000000 1 0 2 0 154 5000K 5K 5005K ? <unknown>
4600000 0 0 0 1 0 5000K 0B 5000K ? <unknown>
2200000 9 50 0 59 84 1944K 3K 1948K 5025 Do
4400000 2 4 0 60 85 695K 2K 698K 15156 gnome-appearan
1200000 257 74 0 23 129 126K 10K 137K 5000 Panel
7800000 50 64 4 74 45 66K 7K 73K 26490 emacs
3e00000 246 61 8 64 145 35K 18K 53K 9082 emacs
1600000 3 26 0 89 2076 356B 49K 49K 5113 gnome-screensa
6000000 3 1 0 4 15 48K 456B 48K 9103 knotify4
4800000 3 1 0 4 15 48K 456B 48K 5365 kded4
5000000 29 28 2 6 1915 9B 48K 48K 15162 metacity
5200000 117 56 6 57 95 35K 12K 47K 14664 emacs
3800000 49 54 8 47 55 35K 11K 46K 27595 emacs@cervante
6e00000 100 65 6 52 65 35K 11K 46K 10473 emacs
5400000 50 55 6 49 59 35K 9K 44K 18736 emacs

Since these results were printed, I have eliminated all GUI apps except 3*emacs, firefox, 2*gnome-terminal, and the basic panel applets including workspace switcher, drive mounter, stickynotes, clock, volume control, network manager, and system monitor. X is still using 1222MB virtual and 261MB RES.

Other big memory hogs (not necessarily X memory) have been update-manager (90MB), beagle, and apt-get.

A number of the drivers and one of the fonts are reported to take up around 28MB or 43MB of virtual memory.
/proc/4199/maps
00400000-005c3000 r-xp 00000000 08:06 28286996 /usr/bin/Xorg
007c3000-007c5000 r--p 001c3000 08:06 28286996 /usr/bin/Xorg
007c5000-007d0000 rw-p 001c5000 08:06 28286996 /usr/bin/Xorg
007d0000-007e1000 rw-p 007d0000 00:00 0
017a1000-3ff19000 rw-p 017a1000 00:00 0 [heap]
4012a000-4012c000 rwxp 00000000 00:0f 719 ...

X server resident memory usage went back up to 500MB and stayed that way even after I killed all GUI programs except the terminal and panel applets. Logged out and back in to restart X server. Usage went down to 200MB virtual and 69MB resident. Reloading firefox, and all my tabs, did not affect X server memory usage. Reading a document:
ftp://ftp.ams.org/pub/tex/doc/amsfonts/amsfndoc.pdf
(font heavy, since it describes a font) using okular caused X server resident memory to jump up to 200MB and virtual memory to increase by about the same amount. However, this memory was freed when I exited okular. Using evince to read the same document did not cause any increase in X server usage. xrestop is still reporting 17MB of usage.
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28137 root 20 0 200m 66m 15m S 0.3 6.7 0:53.35 Xorg

Couple more remarks.
I am using twinview on two 1600x1200 monitors.
Shitwave flush is not installed. Well, actually it may be as it shows up on about:plugins but swfdec gets first dibs and it doesn't play flash without permission. And it doesn't get that very often. Particularly since it doesn't work on most sites, anyway.
Running glxgears doesn't seem to change X server memory usage. So loading the GL driver doesn't seem to be a problem.

After skimming through this 1300 page document with okular:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
Memory usage went up and it did not go back down:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28137 root 20 0 379m 240m 14m S 0.3 24.4 3:22.85 Xorg

I paged down through several hundred pages, some fast enough for the pages to be fully rendered, others not. Memory use went up early and then seemed to stabilize.

Leading me to suspect that the bugs in okular are exciting the bugs in X.

Someone else mentioned another document from this site and okular. Perhaps certain document excite the bugs in okular.

This is a document I had been reading earlier.

I opened the document again, and a curious thing happened. Resident memory went down while virtual memory went up. The resident portion then climbed back up again. When I exited okular the second time, the X server freed the memory.

Restarted okular again. It resumed at the page I was at when I exited the last time. Virtual memory used by the X server almost instantly doubled from 200MB to 400MB, I think. Went back down again to near its initial value, then climbed back up to 368MB/230MB as a paged down. Went back down to 200MB when I exited the program. Rinse, lather, repeat. X virtual memory usage goes up to about 360MB when actively using okular on this document. Frequently goes down to normal when I exit. Loaded n1256.pdf from the same website. X Virtual memory climbed to 366MB. After page down about 40 pages, it suddenly dropped to around 200MB. But then it climbed again to 366Mb. So, okular likes to use about 160MB of server memory when it is running.
I then opened both documents simultaneously in two instances of okular. X virtual memory went up to about 379MB, then stayed there, even actively paging through both documents. So okular seems to share its memory allocation between instances (two separate processes). Exited both and the memory usage did not go back down much, it stayed at 342MB virtual/201MB resident. Reloaded both documents individually and memory didn't go back down. Even after exiting the program again. But memory didn't go up much paging the documents, indicating that okular is still reusing the memory. xrestop, incorrectly shows that okular is using about 40MB.

It seems like okular does some peculiar sharing of pixmap usage between processes. And when more than one is running, it may get a little confused about freeing it when it exits.

http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
These documents are the C99 and C++ standards drafts.

So, looks like the problem is somewhat reproducible.

This problem is reminiscent of similar problems with shmget(). You could either create a private shared memory segment, in which case you could only share it with subprocesses, or you created a public one. If you created a public one, it was not automatically deleted when your process exited or when the last process sharing the segment exited. At least there, you could run a utility program to clean up.

Sure enough, the semantics of XShmCreatePixmap and XShmCreatePixmap look similar, but less documented regarding cleanup and with no utility.
http://www.xfree86.org/current/mit-shm.html
However, these shared memory segments are allocated using shmget().

I checked, and okular's Xshm does not show up in ipcs.

KSharedPixmaps "exist only on the server", implying the server creates them, not the client. And no shmget() would be expected to be used because applications share a common X server.
http://api.kde.org/2.2-api/classref/kdeui/KSharedPixmap.html
http://developer.kde.org/documentation/library/3.1-api/kdeui/html/ksharedpixmap_8cpp-source.html

It uses XInternAtom and XConvertSelection
It appears to create a selection named KDESHPIXMAP:xxxxxx
xlsatoms doesn't show any such atom names.

OpenGL may have its own pixmap sharing mechanisms.

I still suspect this is a shared pixmap issue, though I haven't found the specific shared pixmap mechanism in use.

I see this as the intersection of a number of bugs:
   - X or OpenGL failure to implement reference counting, close on last client exit semantics or incorrect implementation.
   - X or OpenGL failure to provide utilities to list and destroy orphaned shared pixmaps
   - xrestop failure to account for shared pixmaps
   - Okular - improper freeing of shared resources
   - X server/utils failure to identify application which created each retained resource.
Looks like yet another case of bugs compounded by other bugs. If even one module had been implemented correctly, the problem either would not occur or there would at least be a workaround that would help you clean up the mess or identify the culpret.

I do think I have collected enough information that this can be reproduced (with low but practical probability) and that it can be escalated upstream to nvidia AND okular. Even if the problem can't be reproduced on a particular machine, it appears that it is related to okular shared pixmap storage on the server and that can be analyzed.

Okular probably isn't the only app which has this problem, but it is one that is known to have this problem. And it is not just an Okular bug since the X server allows applications to create messes that outlive the application and doesn't provide a way for the user to identify the application causing the problem and to clean up the mess.

A few lines from strace may be of interest, though strace bombs out pretty early.
It suggests okular is using the MIT-SHM extension for something, though if that were the problem the memory would show up in ipcs and would show up as shared memory in top. I think the problem is in server side allocated "shared" memory

strace okular /tmp/n2798.pdf 2>&1 | egrep -i "shm|pixmap" | fgrep -v ENOENT
writev(7, [{"b\0\4\0\7\0\0\0"..., 8}, {"MIT-SHM"..., 7}, {"\0"..., 1}], 3) = 16
writev(7, [{"b\0\4\0\7\0\0\0"..., 8}, {"MIT-SHM"..., 7}, {"\0"..., 1}], 3) = 16
writev(16, [{"b\0\4\0\7\0\0\4"..., 8}, {"MIT-SHM"..., 7}, {"\0"..., 1}], 3) = 16
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0\177r\26\0\0"..., 4096) = 4096
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0f\274\1\0R"..., 4096) = 4096
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0\177r\26\0\0"..., 4096) = 4096
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0f\274\1\0R"..., 4096) = 4096
lstat("/usr/share/pixmaps", {st_mode=S_IFDIR|0755, st_size=32768, ...}) = 0
stat("/usr/share/pixmaps", {st_mode=S_IFDIR|0755, st_size=32768, ...}) = 0
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0\177r\26\0\0"..., 4096) = 4096
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0f\274\1\0R"..., 4096) = 4096
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0\177r\26\0\0"..., 4096) = 4096
read(19, "KDE PIXMAP CACHE DEUX\177\0\0\10\2\0\0f\274\1\0R"..., 4096) = 4096
*** glibc detected *** strace: malloc(): memory corruption (fast): 0x0000000000f6f610 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f3c20dc5cb8]
/lib/libc.so.6[0x7f3c20dc9351]
/lib/libc.so.6(__libc_malloc+0x98)[0x7f3c20dca828]
strace[0x4087d8]
strace[0x405c0e]
strace[0x404916]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f3c20d6c5a6]
strace[0x402119]

Cross-reference:
This was added as a comment on a related okular bug:

https://bugs.kde.org/show_bug.cgi?id=177213

Xorg's memory consumption goes up each time the tty is switched to or from the one running the X server, and each time the box is suspended & resumed. The increase at each step depends on the 'pixmem' size.

In the following, I switched between tty1 (CLI) and tty7 (X) and took a reading each time I returned to tty7. Only `firefox` and `gnome-terminal` windows were open.

$ top -bn1 |grep Xorg
 2816 root 20 0 556m 63m 17m S 2 1.6 0:06.87 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 606m 79m 20m S 0 2.1 0:08.54 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 653m 92m 23m S 2 2.4 0:10.30 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 701m 106m 25m S 0 2.7 0:12.19 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 750m 117m 27m S 0 3.0 0:13.95 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 798m 130m 30m S 2 3.4 0:15.74 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 845m 144m 32m S 0 3.7 0:17.52 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 893m 157m 35m S 0 4.1 0:20.08 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 960m 210m 44m S 2 5.4 1:01.58 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 1007m 229m 46m R 70 5.9 1:08.70 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 1052m 242m 49m S 74 6.2 1:17.90 Xorg
$ top -bn1 |grep Xorg
 2816 root 20 0 1101m 257m 51m R 71 6.6 1:23.54 Xorg

In the following, there was one suspend & resume between any two consecutive commands. Again, only `firefox` and `gnome-terminal` windows were open.

$ top -bn1 |grep Xorg
23595 root 20 0 526m 103m 24m S 4 2.7 3:59.37 Xorg
$ top -bn1 |grep Xorg
23595 root 20 0 587m 123m 24m S 6 3.2 4:03.11 Xorg
$ top -bn1 |grep Xorg
23595 root 20 0 675m 145m 25m S 4 3.8 4:11.56 Xorg
$ top -bn1 |grep Xorg
23595 root 20 0 723m 160m 26m S 4 4.1 4:23.90 Xorg

`xrestop`'s output showed no significant change, but the increases in Xorg's resident memory in each step approximately equal to the total memory according to `xrestop`:
          Pixmaps: 17925K total, Other: 122K total, All: 18047K total

The box is running Jaunty, amd64; all packages are up to date.
$ lspci |grep Display
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
$ cat /proc/version
Linux version 2.6.28-11-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009

After using my pc for a while almost always Xorg's memory grows to 1GB or more. I haven't read all the posts here. But in case you need any more info you may need in fixing this bug, please let me know.

uname -a
Linux scspc259.cs 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:32 UTC 2009 x86_64 GNU/Linux

confirmed on Ubuntu Karmic AMD64, with fglrx from Catalyst 9.11. 1GB HD4670 desktop card. Okular makes server memory consumption go up, but it doesn't go down even after exitting everything.

This has been discussed on the xorg list.
http://lists.x.org/archives/xorg/2008-December/041324.html

http://www.phoronix.com/forums/showthread.php?t=19637

reported to ATI as http://ati.cchtml.com/show_bug.cgi?id=1703, but it's probably not driver-specific.

I can also confirm this that on Ubuntu Karmic AMD64, with nvidia drivers, Xorg uses a lot of memory (about 1.5GB).

Confirming Xorg uses over 1GB of ram on karmic 64bit, with nvidia drivers 190.

I'm seeing a very large X process.

I have an ATI x1600 ("ATI Technologies Inc M56GL [Mobility FireGL V5200]") on a Thinkpad t60p (2007-AD1).

X typicaly uses right around 1GB of virtual memory - but xrestop shows a /total/ of 120MB in pixmaps in 61 clients - compiz has about 22MB, as does Firefox 3.0.17.

X info:

X.Org X Server 1.6.0
Release Date: 2009-2-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
Current Operating System: Linux chubby 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC 2009 i686
Build Date: 09 April 2009 02:10:02AM
xorg-server 2:1.6.0-0ubuntu14 (<email address hidden>)

Here is pmap output from /usr/bin/X only showing those entries larger than 1024KB - anon is only 33% of the total on my system:

Address Kbytes RSS Anon Locked Mode Mapping
08047000 1656 - - - r-x-- Xorg (deleted)
09e88000 104908 - - - rw--- [ anon ]
419fe000 1260 - - - r-x-- libcrypto.so.0.9.8 (deleted)
4710a000 1392 - - - r-x-- libc-2.9.so
7eb99000 12096 - - - rw--- [ anon ]
80930000 13692 - - - rw--- [ anon ]
8168f000 16384 - - - r--s- [ shmid=0x2b6801f ]
82818000 27720 - - - rw--- [ anon ]
8433e000 12800 - - - rw--- [ anon ]
85171000 13224 - - - rw--- [ anon ]
85e6d000 11904 - - - rw--- [ anon ]
86db6000 12044 - - - rw--- [ anon ]
87e32000 6544 - - - rw--- [ anon ]
884a3000 8316 - - - rw--- [ anon ]
89871000 15144 - - - rw--- [ anon ]
8a887000 5432 - - - rw--- [ anon ]
8af7a000 1300 - - - rw--- [ anon ]
8b89f000 9032 - - - rw--- [ anon ]
8c660000 2144 - - - rw--- [ anon ]
8c8d8000 5572 - - - rw--- [ anon ]
8cf4d000 5572 - - - rw--- [ anon ]
8dd5b000 6612 - - - rw--- [ anon ]
8ea90000 14740 - - - rw--- [ anon ]
8fa07000 1060 - - - rw--- [ anon ]
90204000 6612 - - - rw--- [ anon ]
90a3b000 1060 - - - rw--- [ anon ]
90e44000 30708 - - - rw--- [ anon ]
92eaa000 1556 - - - rw--- [ anon ]
936f1000 1544 - - - rw--- [ anon ]
93964000 1284 - - - rw--- [ anon ]
93b68000 29184 - - - rw-s- card0
957e8000 2048 - - - rw-s- card0
959fb000 262112 - - - rw-s- card0
a59f3000 2192 - - - r-x-- r300_dri.so
a5c38000 2048 - - - rw-s- card0
a5e38000 29184 - - - rw-s- card0
a7ab8000 2048 - - - rw-s- card0
a7cb8000 262144 - - - rw-s- resource0_wc
b7d57000 1028 - - - rw-s- card0
total kB 972476 - - -

Hope this helps....

I only found this bug tonight - I don't want to seem impatient for a response :-) but I dug a bit deeper, and tried a series of different settings in xorg.conf. My ATI card (too "old" now for fglrx) using the radeon driver does offer some configuration options.

I ultimately decided that --- with my 256MB RAM video card, and with X duplicating that size in virtual memory /twice/ --- that I'd try this Device-section setting:

    VideoRam 128000

Now, /usr/bin/X starts up and uses about 400MB (at login prompt). When you login, it jumps to a bit over 500MB (running Compiz here) - that's 300 MB less than usual.

I've tried 3d accelerated games on this laptop like the wonderful Penumbra trilogy) and they just don't cut it - so as long as I can function day-to-day in Compiz with my 'heavyweight' business/development apps, I'm ok this way.

I'd like to understand why 2x the card RAM size needs to be allocated, though :-/ Once my machine starts swapping, it gets ugly fairly quickly.

Maybe this will help someone - and I'll still be watching for some solution to this issue. This is NOT windows, after all..... :-)

So I've one of these memory leaks. How do I figure out which app does it?

@Shahar Could you run `top` in a terminal and sort the output by memory usage by hitting "F n <enter>", and then take a look at the %MEM column?

Dear Aaditya,

This is what it looks like:

top - 17:19:52 up 9:54, 3 users, load average: 0.49, 0.43, 0.56
Tasks: 172 total, 3 running, 169 sleeping, 0 stopped, 0 zombie
Cpu(s): 30.9%us, 41.9%sy, 0.0%ni, 27.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1026432k total, 955660k used, 70772k free, 23548k buffers
Swap: 481940k total, 346816k used, 135124k free, 222696k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 1398 root 20 0 1176m 252m 6640 R 38.1 25.2 28:14.74 Xorg
 4516 dawn 20 0 360m 60m 29m S 0.0 6.0 0:28.35 chrome
 4705 dawn 20 0 123m 50m 12m S 0.0 5.0 0:05.80 chrome
 2079 dawn 20 0 187m 25m 12m S 0.0 2.5 0:50.18 nautilus
30699 dawn 20 0 166m 22m 14m S 0.0 2.2 0:08.96 empathy
 4636 dawn 20 0 107m 22m 11m S 0.0 2.2 0:01.37 chrome
 4513 dawn 20 0 117m 21m 17m S 27.8 2.1 0:43.84 gnome-system-mo
 4548 dawn 20 0 106m 20m 11m S 0.0 2.0 0:02.59 chrome
 2072 dawn 20 0 156m 16m 8208 S 0.0 1.7 1:29.02 gnome-panel
 4617 dawn 20 0 117m 16m 9m S 1.3 1.6 0:00.68 chrome
 4596 dawn 20 0 100m 15m 9952 S 0.0 1.5 0:00.50 chrome
 4654 dawn 20 0 100m 14m 9268 S 1.3 1.5 0:00.60 chrome
 4642 dawn 20 0 99.4m 13m 9828 S 0.0 1.4 0:00.35 chrome
 4601 dawn 20 0 100m 13m 9424 S 0.0 1.4 0:00.45 chrome
 4646 dawn 20 0 99.8m 13m 8664 S 0.0 1.4 0:00.44 chrome
28154 dawn 20 0 121m 13m 10m S 1.0 1.3 0:15.08 gnome-terminal
 4613 dawn 20 0 100m 13m 8780 S 0.0 1.3 0:00.36 chrome
30864 dawn 20 0 18104 12m 3188 S 0.0 1.2 0:03.40 telepathy-butte
 4560 dawn 20 0 99.2m 12m 7976 S 0.0 1.2 0:00.24 chrome
 4663 dawn 20 0 99.1m 11m 7848 S 0.0 1.2 0:00.19 chrome

@Shahar
It's clearly a memory leak in Xorg since that's taking up 25% of your 1GB, that is, around 250MB.

I'd advise you to discuss the issue on IRC [1] in #ubuntu-bugs . They can help you pull more information from your system so that you can post it here for developers' attention.

[1] https://help.ubuntu.com/community/InternetRelayChat

Just adding my two cents to the party...

I've also been noticing excessive RAM usage in Xorg, having spent several weeks dealing with it - I've narrowed it down to the wallpaper-tray app I was running, also happens with Drapes (i.e. - when the wall paper changes frequently). Since having settled on a wallpaper, Xorg looks like such:

1673 root 20 0 160m 65m 21m R 10 1.7 13:30.42 Xorg

As compared to having it eat as much as 1GB of ram after several hours of usage.

I'm running Ubuntu 9.10 64bit, Nvidia 9800GTm with the proprietary 195.36 Beta drivers (also tested on the "Official Nvidia" drivers 190.53 with the same result). Tested with both stock Xorg packages and Xorg from x-swat repo (currently in use):

dpkg -l |grep xorg:
xorg 1:7.4+3ubuntu10
xserver-xorg 1:7.4+3ubuntu10
xserver-xorg-core 2:1.6.4-2ubuntu4

Please let me know if you need anything else... This issue is easily reproducible for me.
Daniel

I used to have similar issues with Xorg using up 300-400 MB after a couple of hours usage. Now that I've upgraded to lucid and KMS (radeon driver), Xorg stays at about 60 MB.

Is this problem solved for anybody else with lucid?

Hi,

I've tried lucid a couple of days and Xorg is using about 240-270MB virtual memory (120-140MB resident), which is much better than the 1.5GB it used on karmic, but I'm not sure if the bug is fixed, or whether I just need to run it a while longer.

I tried running okular with the pdf files mentioned above. It does increase Xorg's memory usage by about 100MB, but it is accounted for in xrestop, and released after okular is closed.

I am using Lucid, Radeon Open Source driver, KDE and I have compositions enabled. Xorg's memory usage is very high in Kubuntu compared to Arch Linux - sometimes over 100MB to 30MB in Arch.

Confirmed, Kubuntu Lucid x64, xorg takes up to 500MB, and cca 50% of CPU after e.g. day of using.

Jesus how can it be a wishlist?? It is a memory LEAK, wht can be worse? The impossibility to running the OS?

OK thanks for help.

700MB....

Tommy, please, be serious, only report new records of memory usage.
Your 700MB is nothing compared to what other people have, on the order of 1-2GB.
;-)

uptime:
07:11:31 up 6 days, 7:42, 1 user, load average: 0.47, 0.73, 0.77

/usr/bin/X -nolisten tcp :0 -dpi 110 -auth /tmp/...
RES: 959M

And it will increase memory usage hour by hour, day by day...

Some infos about packages:

ii xserver-xorg 1:7.5+6+xserver1.9 the X.Org X server
ii xserver-xorg-core 2:1.9.0+git20100902+server-1.9-branch.79ee78de-0ubuntu0sarvatt Xorg X server - core server
ii xserver-xorg-input-all 1:7.5+7 the X.Org X server -- input driver metapackage
ii xserver-xorg-input-evdev 1:2.5.0+git20100822.990540fa-0ubuntu0sarvatt X.Org X server -- evdev input driver
ii xserver-xorg-input-mouse 1:1.5.0+git20100812.374725ef-0ubuntu0sarvatt X.Org X server -- mouse input driver
ii xserver-xorg-input-synaptics 1:1.2.99+git20100610.a489ec15-0ubuntu0sarvatt2 Synaptics TouchPad driver for X.Org server
ii xserver-xorg-input-vmmouse 1:12.6.10+git20100811.adc177e3-0ubuntu0sarvatt X.Org X server -- VMMouse input driver to use with VMWare
ii xserver-xorg-input-wacom 1:0.10.7+git20100706-0ubuntu0sarvatt X.Org X server -- Wacom input driver
ii xserver-xorg-video-radeon 1:6.13.99+git20100907.b90cb61c-0ubuntu0sarvatt X.Org X server -- AMD/ATI Radeon display driver

I have this issue about two years on every laptop (or PC) I had (no matters which GPU/driver I used, or which version of X I ran [stable or devel]). "Workaround" is restart X server after 3-5 days of use (really annoying).

I am able to reproduce this consistently on maverick. xorg virtual memory increases by 8MB every time I change the desktop background. xrestop is stable.

Running the intel driver, compiz, nautilus.

Linux mimiv 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 10:18:49 UTC 2010 i686 GNU/Linux

ii xserver-xorg-video-intel 2:2.12.0-1ubuntu5.1
ii xorg 1:7.5+6ubuntu3 X.Org X Window System
ii xserver-xorg 1:7.5+6ubuntu3 the X.Org X server
ii xserver-xorg-core 2:1.9.0-0ubuntu7 Xorg X server - core server

Let me know what other information I can provide.

This seems related to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/658746 .

  cat /sys/kernel/debug/dri/0/gem_objects | grep 'object bytes'

increases with each desktop background swap.

Closing this one, since 1.10.1 in natty has all the memleaks fixed that were found with analyzer tools.

When the Xorg process shows taking a lot of memory, it's usually a rogue client or the display driver leaking, and the xserver is caching pixmap memory. This is not a bug in the xserver, and should be filed against the client or the driver.