On Tue, 9 Jan 2001, Szabolcs Szakacsits wrote:
> 3) ask kernel developers to get rid of this "brk hits the fixed start
> address of mmapped areas" or the other way around complaints "mmapped
> area should start at lower address" limitation. E.g. Solaris does
> growing up heap, growing down mmap a
On Tue, 9 Jan 2001, Szabolcs Szakacsits wrote:
> Wayne, the patch below should fix your barrier problem [1 GB physical
> memory configuration].
First, I just wanted to thank you and everyone else (Linus, Andrea, Dan
Maas, Rik and others) who has responded to my emails. You guys are
wonderful!
On Tue, 9 Jan 2001, Dan Maas wrote:
> 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.
[... good explanation here ...]
> Here's your short answer: ask the authors of your program to either
> 1) replace
> 08048000-08b5c000 r-xp 03:05 1130923
/tmp/newmagma/magma.exe.dyn
> 08b5c000-08cc9000 rw-p 00b13000 03:05 1130923
/tmp/newmagma/magma.exe.dyn
> 08cc9000-0bd0 rwxp 00:00 0
> Now, subsequent to each memory allocation, only the second number in the
> third line changes. It be
On Mon, Jan 08, 2001 at 03:22:44PM -0800, Wayne Whitney wrote:
> I guess I conclude that either (1) MAGMA does not use libc's malloc
> (checking on this, I doubt it)
I'm still a bit unclear on this one. I now have two executables,
magma.exe and magma.exe.dyn (ignore the .exe). magma.exe is st
5 matches
Mail list logo
