Jonathan H. Aseltine | 4 Oct 08:49 1996
Picon

build fail w/ Linux 2.0.21

Version: 0.45

...
[inspect-commands
./scheme/env/inspect.scm ]
[disassemble-commands
./scheme/env/disasm.scm ]
]
Scheme48 heap overflow
make: *** [scheme48.image] Error 255

-- Jon Aseltine

Eric M. Kidd | 15 Oct 22:57 1996

VM Bugs

Greetings,

I ported Scheme 48 to the BeOS last night (see <http://www.be.com/> for more
information). The configuration and make files needed a substantial bit of
hand-hackery because of local compiler bugs, and I made a few general, cosmetic
improvements to unix.c.

The file scheme48vm.c assumes that char* and unsigned char* are equivalent in
about 6 or 7 places; this is not a safe assumption with exceptionally picky
compilers. This is easy enough to fix by hand.

I'll send you the source for these changes Real Soon Now.

There's one big bug, though, which I still haven't worked around. The PreScheme
version of write-image uses signed 32-bit integers to represent pointers. The
BeOS kernel allocates process heaps above 0x80000000. When write-image outputs
the image header, the last three ASCII-printed numbers before the endianess
indicator appear as negative numbers. The build-usual-image script creates
scheme48.image, but scheme48vm refuses to reload it, claiming that there isn't
enough memory. How much work would it take to fix this?

If I have a moment tonight, I'll try to build scheme48.image using the linker
instead of the vm dump routine. This will allow me to run the test suites.

Thanks for maintaining Scheme48!

Cheers,
Eric

(Continue reading)

Margaret M Fleck | 30 Oct 20:15 1996
Picon

compiler and memory usage


We are having trouble tracking down a problem with heap overflows.  

As best we understand it, the problem is as follows:

   As we load our code package, scheme48 uses more and more
   memory.  My RS 6000 has 64M of virtual memory and scheme48
   sometimes gobbles 70% according to the ps listing.  

   Our code builds a few tables, but they are fairly small.
   Our code package is of modest size.  70% is a truly unusual 
   amount of memory to be nailing down:  Franz Common Lisp + 
   our giant utility package + 10 or so large digitized images almost 
   never exceeds 50% memory usage.  

   Sometimes scheme48 crashes reporting "heap overflow" at this
   point.  This doesn't always happen:  sometimes restarting
   scheme and doing exactly the same thing will not cause a crash.
   Whether it crashes or not seems to depend on what other programs
   are running (particularly system-hogging monsters like netscape).  

   I think the crashes are a side-effect and the real problem is
   that it is asking for excessive amounts of memory from the OS.

   If scheme survives, the memory usage decreases over the next
   few minutes and returns to a sensible level.     

   There seems to be a similar problem when a command prints a
   large amount of stuff to the terminal.

(Continue reading)

Richard Kelsey | 30 Oct 21:28 1996
Picon

Re: compiler and memory usage


   Date: Wed, 30 Oct 1996 14:15:29 -0500
   From: Margaret M Fleck <mfleck <at> cs.uiowa.edu>

   We are having trouble tracking down a problem with heap overflows.  

   [...description elided...]

Part of your problem is that there are two bugs in 0.45 that
manifest themselves  as heap-overflow messages.  One causes
the heap to fill up and Scheme 48 to die if stdout blocks.
This can happen if you dump a lot of output to a terminal.
The other causes spurious heap-overflow messages when there
is still plenty of space left in the heap.  From your message
I suspect that your are running into both of these.

Both problems have been tracked down and a new release will
be available shortly.

I do not understand why your Scheme 48 is using so much memory.
The heap is allocated on startup and is never extended (hence
the heap-overflow messages).  With the default heap size, which
you said you were using, a Scheme 48 process uses about 6M of
virtual memory.  After startup it allocates at most a few K.
This is far less than the 40M you said was being used.

If the system were requesting additional memory from the OS and
not getting it you should get a different error message.

The only thing that might allocate larger amounts of memory is
(Continue reading)


Gmane