Most recent kernel where this bug did not occur: 2.6.11 Distribution: Gentoo Linux Hardware Environment: AMD Sempron 2800+ Software Environment: Home workstation computer Problem Description: kernel produces a memory leak that uses up all the physical memory and freezes the computer up completely Steps to reproduce: Run the kernel version 2.6.12 with the gentoo-sources patchset , revision 6. Slowly but surely the used memory will increase endlessly until the computer locks up completely.
Could you please take copies of /proc/meminfo and /proc/slabinfo when the machine is close to being out of memory?
Also this is bugzilla for the vanilla (kernel.org) kernel, please use that so that we can be sure that it isn't something gentoo specific causing this.
I believe I'm seeing a similar problem however I believe it is the way the memory usage is being reported. Running 2.6.12-1.1372_FC3smp fedora Lately the ext3_inode_cache seems to be using up large amounts of memory in my case 400MB of 1G. This does not seem to get reported via the usual user / cache / buffers memory. It is viewable via slabtop. My system is continually sitting on just under 1Gig of used memory a single day after boot. updatedb is run every morning and scans HDD and this eats up a huge amount of resources. Even though this memory may be freed amlost immediately if it is needed (supposedly?) It really should get reported differently. And it doesn't seem to drop over time. Also I have seen swap usage when technically I should have nearly 600+ megs of ram available. based on the fact that at boot the system is only using around 340megs. The buffers amount in memory does increase aswell during the updatedb but only to about half the actual visible increase in utilisation. Hope that helps a bit, and I'm not completely off the mark
Ryan and others who reported the problem, has it been resolved with later kernels? Can you update the status please. Thanks.
Ryan, Richard - we all know linux memory management is a complex thing and not easy to understand. there is much room for misinterpretation. anyhow, this bug report is quite old and none of you gave really detailed information to prove that there really is a leak. you were either seeing crashes or seeing something weird or suspecting that there is a leak, but it`s not comprehensible for others. could you please be more specific and give some input or test if this still exists with a recent kernel ? anyway - too much time gone by.....
Hi Roland I was looking at this issue quite a while back :) I was inferring in my comment that something had changed and perhaps the memory usage reporting mechanism needed updating. However at the time I think it came down to the way most user apps were showing what free memory was.. eg if you do a 'top' and look at the 'free' value it is pretty much always very low. You have to grab say the info from proc/meminfo and look I suppose at the 'active' line which shows how much RAM is actually in use. This shows a much more respectable value. Most user apps I've come across lately report the ram usage better. Just something in the kernel back then changed and the reporting of mem free changed definition perhaps...(or I just noticed this for the first time :) ) Anyway, I never thought there was a leak, just a reporting issue. Cheers, and I think this bug can be closed.