Second Life quickly uses all available memory

On my laptop running Ubuntu 6.06, the Second Life client (1.12.2.9) quickly consumes all system memory, so my machine spends all its time swapping. I have 2 gig of physical memory, plus a gig of swap. If I visit an intensive area like a casino, the client will grow to greater than 2 gigabytes resident in about 5 minutes.

I have a ATI Technologies Inc Radeon R250 Lf [FireGL 9000], with 32 meg of video ram. I'm using the fglrx proprietary accelerated driver for ATI cards, version 8.25.18. It's possible there is a memory leak in the driver, but I haven't found anything on the web supporting that.

I didn't observe this problem when I used MESA software opengl, without the accelerated driver. However, the client was unusably slow (0.7 fps).

Can anyone comment on the ATI driver? Has anyone seen a similar memory usage pattern?

If you can pmap the running sl process it might give a hint to where your memory is going. If something comes back really large post it for us.

I did a pmap of the process on startup, then logged in and let it grow to a gig of memory. The new lines appearing in pmap include first:

09ed8000 1262656K rwx-- [ anon ]

which I presume is just the heap.

Then there are a lot of lines approximately like:
a439f000 4932K rwx-- [ anon ]
a48b2000 256K rwxs- /dev/dri/card0
a4a0b000 260K rwx-- [ anon ]
a4a4c000 1024K rwxs- /dev/dri/card0
a4cdb000 260K rwx-- [ anon ]
a4d1c000 1024K rwxs- /dev/dri/card0
a4eba000 780K rwx-- [ anon ]
a538a000 520K rwx-- [ anon ]
a540c000 256K rwxs- /dev/dri/card0
a544c000 4928K rwx-- [ anon ]
a591f000 260K rwx-- [ anon ]
a5fab000 1028K rwx-- [ anon ]
a60c4000 1024K rwxs- /dev/dri/card0
a61c4000 256K rwxs- /dev/dri/card0
a6204000 260K rwx-- [ anon ]
a625e000 520K rwx-- [ anon ]
a63fb000 520K rwx-- [ anon ]
a64be000 864K rwx-- [ anon ]
a671a000 256K rwxs- /dev/dri/card0
a675a000 520K rwx-- [ anon ]
a692f000 1300K rwx-- [ anon ]
a6c02000 256K rwxs- /dev/dri/card0
a6c42000 260K rwx-- [ anon ]
a6da1000 260K rwx-- [ anon ]
a6ffd000 780K rwx-- [ anon ]

I presume these are mapped regions of video memory or some such. While there are many of them, they only add up to a few dozen megabytes.

So it seems like heap allocated memory is what is killing me.
Maybe I'll try looking for leaks with mmap next.

Oops. First, I meant valgrind, not mmap.

Second, valgrind isn't working on my ubuntu system for some reason. So I'm not going to do that unless someone really thinks it will help, in which case I will first figure out how to fix valgrind.

Right off I noticed when I set the disk cache to 1gb my performance was killed. I run a dual core Athlon 64 with 2gb of memory. My systtem barely hits 250mb with firefox running. But when the cache is over 500mb it chokes the system, however it works great when set to 500mb. It might be a problem handling and caching so many textures. Also anything in the memory of the graphics card will also reside in system memory. Note that graphics memory was only for faster access to textures and what not, it is still mirrored by the system.

I am having the same problem with the 1.12.2.9 client.

I am running Fedora Core 5, NVidia 6600GT, and the NVidia 1.0-9625 beta driver.

This did not happen with previous clients after being in world for hours.

I tried a ulimit in the startup script and SL exited almost immediately.

It does not happen every time I login, but has happened pretty consistently today.

I have tried cutting my cache back to 200M to see if it helps.

While SL is running, watching the process with top, I see ~750MB of virtual memory used, ~625MB resident memory, and ~30MB of shared.

same bug here; Ubuntu Dapper, Nvidia FX5200, 512MB RAM, client 1.12.2.9 (NVIDIA binary driver)
turning the size of the disk cache down helps but it is still unplayable (<5 FPS) with a 50MB disk cache.

Not sure if this is useful info or not, but the low FPS is only apparent when many elements are drawn on the screen. If i dont look at stuctures, ppl and etc i can get 15 FPS. uncommenting or commenting the GL environment options in the secondlife script does not seem to affect this.