linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Levenstein <romix@geocities.com>
To: "Benjamin C.R. LaHaise" <blah@kvack.org>, Linux-MM@kvack.org
Subject: Re: Strange  memory allocation error in 2.2.11
Date: Fri, 13 Aug 1999 14:44:38 +0000	[thread overview]
Message-ID: <37B42F56.FBAB01A4@geocities.com> (raw)
In-Reply-To: <Pine.LNX.3.96.990813080203.24615A-100000@mole.spellcast.com>

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

  reply	other threads:[~1999-08-13 14:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-13 13:30 Roman Levenstein
1999-08-13 12:20 ` Benjamin C.R. LaHaise
1999-08-13 14:44   ` Roman Levenstein [this message]
1999-08-13 14:49     ` Benjamin C.R. LaHaise
1999-08-13 17:24       ` Chris Atenasio
1999-08-13 22:53         ` Benjamin C.R. LaHaise

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37B42F56.FBAB01A4@geocities.com \
    --to=romix@geocities.com \
    --cc=Linux-MM@kvack.org \
    --cc=blah@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox