Strange memory allocation error in 2.2.11

Strange memory allocation error in 2.2.11

[Roman Levenstein]

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Strange memory allocation error in 2.2.11

[Benjamin C.R. LaHaise]

On Fri, 13 Aug 1999, Roman Levenstein wrote:

> 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?

> 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.

> 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Strange memory allocation error in 2.2.11

[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?

 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
> 
> > 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.
> 
> > 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Strange memory allocation error in 2.2.11

[Benjamin C.R. LaHaise]

On Fri, 13 Aug 1999, Roman Levenstein wrote:

> > > 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

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.

>  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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Strange memory allocation error in 2.2.11

[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.

2.2.10 works fine.

oh, and this *is* egcs-2.91.66...

- Chris
-----------------------------------------------------------------------------
Chris Atenasio <chrisa@flashcom.net> - 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Strange memory allocation error in 2.2.11

[Benjamin C.R. LaHaise]

On Fri, 13 Aug 1999, Chris Atenasio wrote:

> 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/