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
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 and
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
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
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
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 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
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
10 matches
Mail list logo
