4 Oct 1996 08:49
15 Oct 1996 22:57
VM Bugs
Eric M. Kidd <Eric.M.Kidd <at> Dartmouth.EDU>
1996-10-15 20:57:48 GMT
1996-10-15 20:57:48 GMT
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)
30 Oct 1996 20:15
compiler and memory usage
Margaret M Fleck <mfleck <at> cs.uiowa.edu>
1996-10-30 19:15:29 GMT
1996-10-30 19:15:29 GMT
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)
30 Oct 1996 21:28
Re: compiler and memory usage
Richard Kelsey <kelsey <at> research.nj.nec.com>
1996-10-30 20:28:21 GMT
1996-10-30 20:28:21 GMT
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)
RSS Feed