Re: Subtle MM bug (really 830MB barrier question)

["Dan Maas" <dmaas@dcine.com>]

> 08048000-08b5c000 r-xp 00000000 03:05 1130923
/tmp/newmagma/magma.exe.dyn
> 08b5c000-08cc9000 rw-p 00b13000 03:05 1130923
/tmp/newmagma/magma.exe.dyn
> 08cc9000-0bd00000 rwxp 00000000 00:00 0

> Now, subsequent to each memory allocation, only the second number in the
> third line changes.  It becomes 23a78000, then 3b7f0000, and finally
> 3b808000 (after the failed allocation).

OK it's fairly obvious what's happening here. Your program is using its own
allocator, which relies solely on brk() to obtain more memory. On x86 Linux,
brk()-allocated memory (the heap) begins right above the executable and
grows upward - the increasing number you noted above is the top of the heap,
which grows with every brk(). Problem is, the heap can't keep growing
forever - as you discovered, on x86 Linux the upper bound is just below
0x40000000. That boundary is where shared libraries and other memory-mapped
files start to appear.

Note that there is still plenty (~2GB) of address space left, in the region
between the shared libraries and the top of user address space (just under
0xBFFFFFFF). How do you use that space? You need an allocation scheme based
on mmap'ing /dev/zero. As others pointed out, glibc's allocator does just
that.

Here's your short answer: ask the authors of your program to either 1)
replace their custom allocator with regular malloc() or 2) enhance their
custom allocator to use mmap. (or, buy some 64-bit hardware =)...)

Dan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/