xscreensaver memory leak

[Apreche]

I think there is a memory leak in xscreensaver. Here's the story. I have gkrellm2 running all the time to watch what my pc is doing. I run xscreensaver all night, because this is my computer at work. When I come back in the morning a bunch of RAM has filled up. I do ps -aux to list all the processes and how much ram they are taking up, but nobody seems to be the culprit. The ram might be 75% full as reported by gkrellm, but the total % listed there will be < 10%.

I think this is what the problem is. I am using the Nfornce Integrated Graphics card. This means that my system memory is my video card memory. I have 512 total, and in the BIOS I have set 64MB to be the max to be used by the video card. What I think is happening though is this. I have the screensavers running on random mode and every so often it switches which screensaver is running. I'm running them all using hardware opengl accelleration and I'm using nvidia-kernel and nvidia-glx, the newest versions with a properly configured 2.6 kernel. (all nforce options enabled). What I think happens is that each screensaver takes up a bit of the ram when it loads because it is also the video card ram. Then when the screensavers switch the memory isn't being set free. And obviously the limit I set in the BIOS is being ignored.

I'm not 100% sure that this is the cause of the problem, but it seems reasonable. During the day my memory use doesn't increase unless I run more applications. The only difference between day and night is that xscreensaver runs all night.

Has anyone else had a problem like this? Any known solutions? Anyone who can verify my guess as being right or wrong? Right now the only way I have of freeing up the memory is restarting the pc, not something I like doing. Thanks.

[Epyon]

If I leave my computer on overnight it'll do the same thing. At midnight slocate and updatedb run. They make the ram usage go really high. It's never a problem though since the memory does eventually get reclaimed if something needs it.

[skunkworx]

This may sound like a smart-alec answer, but one obvious way you can determine if xscreensaver is the culprit is simply not run xscreensaver for one night. You can also try killing the xscreensaver daemon and see if that frees up the memory.

I don't think xscreensaver relies entirely on video memory to run, and if a leak is somewhere in the code that runs in system memory, then of course it won't be the 64MB of video memory that gets eaten away.

If not running xscreensaver (or killing it) seems to plug the leak, you can start tweaking xscreensaver's configuration to try and pinpoint the leak. Maybe not run the 3D accelerated modules, or not switch modules as often (or at all), etc. Also check Gentoo's Bugzilla and whatever passes for xscreensaver's bugs/known-issues database to see if the developers are already aware of any leaks.
_________________
Proud to be a... eh, forget it.

"Everyday is just one day." -- not the Traveling Wilburys

[Apreche]

I disabled xscreensaver last night, so my theory was incorrect. The memory still leaked. I think updatedb and slocate are the culprits as epyon suggested. Since the memory is reclaimed it is no big deal. I was just wondering if there was some program I could run/emerge that would clear it out of ram immediately. I need to watch the ram for software development purposes.

[sapphirecat]

[Apreche]

I just manually ran locate -u after a reboot and the ram filled right up to the exact amount as before. There is no question about it. I've got it all cleared out though, so it's all good. It's a cheap hack, but if I allocate and free a few hundred megs it cleans right out because the memory that locate took up is the first to get allocated. Small C program it was yes. Thanks all, sorry xscreensaver for my false accusation.