Messages in this thread | | | From | AJ ONeal <> | Date | Wed, 26 Jan 2011 12:09:51 -0700 | Subject | Re: Memory Leak in /dev/shm on ARM 2.6.36 |
| |
I have another thought which may narrow down the problem a little bit.
Although all open files are closed before being removed, inotify is watching the directory. Perhaps this is a contributing factor? Thoughts?
I'll be trying the 2.6.35 kernel today, perhaps other kernels.
AJ ONeal
On Tue, Dec 21, 2010 at 12:51 AM, AJ ONeal <coolaj86@gmail.com> wrote: > umount does fail, but umount -l succeeds. > > Here's a snippet of the most relevant portion of the code: > https://gist.github.com/749619 > > > The data size is always 512kb > The file write occurs every 128ms (with some hiccups now and then) > 14 writes occur before the first file is overwritten. > > It's not very likely, but possible that another process could have the file > open for reading when it is unlinked, but never written to. > > Luckily I happen to have a 2.6.35 laying around for ARM. > > Perhaps I can just get you a copy of the code to test on x86. > I don't have any handy that I'm okay to swap kernels on. > > AJ ONeal > > On Mon, Dec 20, 2010 at 9:46 PM, Hugh Dickins <hughd@google.com> wrote: >> >> On Mon, 20 Dec 2010, AJ ONeal wrote: >> >> > In my other message about SIGBUS I was mmap-ing a file in /dev/shm. >> > >> > I switched my implementation to use write() instead of mmap and now it >> > leaks memory very very quickly. >> > >> > `df -h` shows that 80mb of memory are in use >> > `du -ch /dev/shm` shows that 10mb of memory in use >> > >> > After just a few minutes of creating and removing 512kb files in >> > /dev/shm the program exits with a write failure. >> > Unmounting and remounting /dev/shm reclaims the memory. >> >> I'm interested, but won't have any time to investigate for several days. >> >> The usual reason (for such a large df/du discrepancy) would be something >> holding open the unlinked files; but if that were the case, then umount >> would fail, complaining that the mount is busy. >> >> Can you please try x86 and see if the same happens there with your >> program? (I've got x86 but not arm: I see no problem on x86, >> but I'm probably not doing exactly what you're doing.) >> >> Can you please try 2.6.35 and see if that behaves in the same way? >> There were some shmem block accounting changes in 2.6.36, I wonder >> if they're misbehaving on arm. >> >> Thanks, >> Hugh > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |