Strange memory allocation error in 2.2.11
Hi,
I've a very strange error on my RedHat 5.2 with 2.2.11 kernel.
I'm writing a program , which actively uses garbage collection, implemented in
a separate library(it scans stack, heap, etc. and relies on the system, when trying to determine start and end addresses of these memory areas , but doesn't contain any assembler low-level code).
It works just fine for kernels <=2.2.9 , but since I've installed 2.2.11 garbage collector behaves very strange:
sometimes it crashes , sometimes it loops forever , sometimes it works Ok.
I think there's a problem with MM in this new kernel. To be sure , I reloaded my
computer with the old (2.2.3) version of kernel and everything works correctly.
Are there any changes in MM for 2.2.11 , which require recompilation of user programs?
What other reasons can lead to such effect?
Thanks in advance,
Roman Levenstein
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 5 lines · Roman Levenstein
I'm writing a program , which actively uses garbage collection, implemented in
a separate library(it scans stack, heap, etc. and relies on the system, when trying to determine start and end addresses of these memory areas , but doesn't contain any assembler low-level code).
Hrmm, how exactly are you extracting this information from the kernel?
Quoted 2 lines
Are there any changes in MM for 2.2.11 , which require recompilation of user programs?
The only changes in 2.2.11 related to mm that could cause this have to do with zeromapping ranges, but it should be a non-change for x86. Also, allocation patterns might be slightly different now as mmap is now allows to wrap around once it reached the top of the address space. Also, a bug in mremap was fixed.
Quoted 1 line
What other reasons can lead to such effect?
Depends on your code =) Do you have a test program that demonstrates the but that we could look at?
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 7 lines
Quoted 5 lines
I'm writing a program , which actively uses garbage collection, implemented in
a separate library(it scans stack, heap, etc. and relies on the system, when trying to determine start and end addresses of these memory areas , but doesn't contain any assembler low-level code).Hrmm, how exactly are you extracting this information from the kernel?
I use this piece of code , to find out the end and start of the heap
and
static data area ( and it doesn't use kernel info directly ):
#if defined(linux) || (defined(sparc) && ! defined(__SVR4))
# define GC_ALIGNMENT 8 // use 8-byte alignment for our
heap
extern int etext;
extern int end;
# define GC_DATA_START (void*)(((unsigned long)(&etext) + 0xfff) & ~0xfff)
# define GC_DATA_END (void*)(&end)
#include <stdlib.h>
#include <unistd.h>
extern "C" void * sbrk(int);
# define GC_GET_HEAP_BOTTOM sbrk(0) # define GC_GET_HEAP_TOP sbrk(0) # define GC_CONFIGURED
#endif
Quoted 10 lines
Quoted 3 lines
Are there any changes in MM for 2.2.11 , which require recompilation of user programs?
The only changes in 2.2.11 related to mm that could cause this have to do with zeromapping ranges, but it should be a non-change for x86. Also, allocation patterns might be slightly different now as mmap is now allows to wrap around once it reached the top of the address space. Also, a bug in mremap was fixed.
Quoted 4 lines
Quoted 1 line
What other reasons can lead to such effect?
Depends on your code =) Do you have a test program that demonstrates the but that we could look at?
Unforunately , I've no such a small program. The GC-library is very
complex and
the program , where I use it , is also very big. I've never had any
problems with GC-library before 2.2.11 , though I use this library since February.
The latest run of the program , for example, hasn't crashed , but it
took 2.50 minutes instead of normal 10 secs. It's definetly something with MM in 2.2.11 ...
Roman Levenstein
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 23 lines · Roman Levenstein
Quoted 7 lines
Quoted 5 lines
I'm writing a program , which actively uses garbage collection, implemented in
a separate library(it scans stack, heap, etc. and relies on the system, when trying to determine start and end addresses of these memory areas , but doesn't contain any assembler low-level code).Hrmm, how exactly are you extracting this information from the kernel?
I use this piece of code , to find out the end and start of the heap
and
static data area ( and it doesn't use kernel info directly ):#if defined(linux) || (defined(sparc) && !
defined(__SVR4))
# defineGC_ALIGNMENT8 // use 8-byte alignment for our
heap
extern int etext;
extern int end;
# defineGC_DATA_START(void*)(((unsigned long)(&etext) +0xfff) & ~0xfff)
# defineGC_DATA_END(void*)(&end)
#include <stdlib.h>
#include <unistd.h>
extern "C" void * sbrk(int);
Quoted 4 lines
# define GC_GET_HEAP_BOTTOM sbrk(0) # define GC_GET_HEAP_TOP sbrk(0) # define GC_CONFIGURED#endif
This is definately wrong -- the bottom and top of heap are definately not equal, and if you're using any sort of recent malloc implementation, it will make use of mmap/munmap, which 2.2.11 can possibly change the allocation patterns of.
Quoted 5 lines
Unforunately , I've no such a small program. The GC-library is very
complex and
the program , where I use it , is also very big. I've never had any
problems with GC-library before 2.2.11 , though I use this library since February.
Well, try comparing the results of strace under different kernels.
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
I will comment that something is definately up with MM in 2.2.11. Although no one else I've asked had this problem, my 2.2.11 almost seems to be unable to deallocate memory, and hangs after a few minutes when all is used up.
2.2.10 works fine.
oh, and this *is* egcs-2.91.66...
- Chris
-----------------------------------------------------------------------------
Chris Atenasio <[email protected]> - Friends don't let friends use Windows. Send mail with subject "send pgp key" or "word of the day" for auto-response. Today's word of the day: displays
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 4 lines · Chris Atenasio
I will comment that something is definately up with MM in 2.2.11. Although no one else I've asked had this problem, my 2.2.11 almost seems to be unable to deallocate memory, and hangs after a few minutes when all is used up.
First things first, get Dave's fix for the tcp memory leak (should be in 2.2.12pre3).
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/