Hello,
> I have attached a small program, hopefully enough documented.
> (No makefile, because no options are used).
[program demonstrating running out of address space with just
realloc() of relatively small chunks of memory, eventually
the stack and an mmapped region overlap]
> I hope this helps to find out if this "feature"
> is our problem or it is definitly a kernel/libc problem.
Very nice test program, thanks !
IMHO, it is a kernel bug. Your first message was a bit unclear about
how much stack space you require, but with the test program, it is
obvious that you can get the `overlap' effect even when you use very
little stack space (as you should in a well-behaved program :-).
realloc() in glibc-2 employs the Linux-specific mremap() system call
with the MREMAP_MAYMOVE flag, which gives the kernel complete freedom
about where to reallocate the (expanded, in your test case) chunk.
The Linux kernel seems to prefer to move the chunk towards higher and
higher addresses. I think it should rather place it somewhere where
interference with the stack is less likely, just like when calling
mmap(0, ...) without the MAP_FIXED argument. Below is an untested
patch for Linux-2.0.x which is likely to fix the problem. Maybe this
is already fixed in 2.3.x, but I doubt it.
Regards,
Wolfram.
--- mm/mremap.c~ Thu Jun 4 00:17:50 1998
+++ mm/mremap.c Wed Feb 2 19:28:30 2000
@@ -134,7 +134,7 @@
new_vma = (struct vm_area_struct *)
kmalloc(sizeof(struct vm_area_struct), GFP_KERNEL);
if (new_vma) {
- unsigned long new_addr = get_unmapped_area(addr, new_len);
+ unsigned long new_addr = get_unmapped_area(0, new_len);
if (new_addr && !move_page_tables(current->mm, new_addr, addr, old_len)) {
*new_vma = *vma;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:08 EST