I often find CMU lisp crashing when running memory-intensive jobs,
and just found that the problem can be reproduced with a rather
minimal example:
Sun Microsystems Inc. SunOS 5.3 Generic September 1993
% lisp
CMU Common Lisp 17f, running on peace
Send bug reports and questions to your local CMU CL maintainer, or to
··········@cs.cmu.edu.
Loaded subsystems:
Python 1.0, target SPARCstation/Solaris 2
CLOS based on PCL version: September 16 92 PCL (f)
CLX X Library MIT R5.02
Motif toolkit and graphical debugger 1.0
* (length (make-list 10000000))
[GC threshold exceeded with 2,007,048 bytes in use. Commencing GC.]
[GC completed with 1,969,456 bytes retained and 37,592 bytes freed.]
[ GC messages galore ]
[GC will next occur when at least 65,935,952 bytes are in use.]
[GC threshold exceeded with 65,937,416 bytes in use. Commencing GC.]
set_auto_gc_trigger: tried to set gc trigger too high! (67934800)
[GC completed with 65,934,800 bytes retained and 2,616 bytes freed.]
[GC will next occur when at least 67,934,800 bytes are in use.]
segv_handler: No mapping fault: 0x0eff8000
segv_handler: Recursive no mapping fault (stack overflow?)
The machine this is running on has plenty of real (512meg) and
virtual memory, so I don't seem how it an legitimately through up
its hands after only "67,934,800 bytes are in use."
I know there is no active dvelopment on CMUCL, but maybe bug fixing ?
As always, any hints are appreciated.
--
Andreas Stolcke ·······@icsi.berkeley.edu
International Computer Science Institute ·······@ucbicsi.bitnet
1947 Center St., Suite 600, Berkeley, CA 94704 (510) 642-4274 ext. 126
From: Andreas Stolcke
Subject: Need help with CMUCL bootstrap (Re: CMUCL memory allocation bug ?)
Date:
Message-ID: <3q04u8$2v8@agate.berkeley.edu>
In article <··········@agate.berkeley.edu>,
I <·······@icsi.Berkeley.EDU> wrote:
>I often find CMU lisp crashing when running memory-intensive jobs,
>and just found that the problem can be reproduced with a rather
>minimal example:
>[GC threshold exceeded with 65,937,416 bytes in use. Commencing GC.]
>set_auto_gc_trigger: tried to set gc trigger too high! (67934800)
>[GC completed with 65,934,800 bytes retained and 2,616 bytes freed.]
>[GC will next occur when at least 67,934,800 bytes are in use.]
>segv_handler: No mapping fault: 0x0eff8000
>segv_handler: Recursive no mapping fault (stack overflow?)
After looking at the C code for the lisp runtime system it sems pretty
clear what is going on: the size of my heap is exceeding a predefined
constant DYNAMIC_SPACE_SIZE, which for sparcs is (sparc-validate.h):
#define DYNAMIC_SPACE_SIZE (0x03ff8000)
or 67076096 decimal, and the GC refuses to enlarge the dynamic space
beyond that. 67meg strike me as rather limiting by today's standards.
At this point there are two questions:
(1) Can I simply increase DYNAMIC_SPACE_SIZE and rebuild lisp, or will this
break some built-in assumptions about memory layout etc.
(2) Assuming (1) is not an obstacle, how does one bootstrap a new system?
I was able to recompile the 'lisp' binary (using the internals.h file
that comes in the binry distribution), but the resulting binary
refuses to load the old core files, even without changing any of
the code or constants.
WARNING: startup-code version (3) different from core version (42).
You may lose big.
interrupt_handle_now: No handler for signal 4?
LDB monitor
ldb>
Is the boostrap procedure for CMUCL documented somewhere?
Any ideas?
--
Andreas Stolcke ·······@icsi.berkeley.edu
International Computer Science Institute ·······@ucbicsi.bitnet
1947 Center St., Suite 600, Berkeley, CA 94704 (510) 642-4274 ext. 126
·······@ICSI.Berkeley.EDU (Andreas Stolcke) writes:
(1) Can I simply increase DYNAMIC_SPACE_SIZE and rebuild lisp, or will this
break some built-in assumptions about memory layout etc.
Yes, you can change these constants. Just make sure that the various
memory areas defined in sparc-validate.h don't overlap each other.
I've hacked up our local copy of CMU CL to give it a much bigger
stack, for example:
#define CONTROL_STACK_START (0xe1000000)
#define CONTROL_STACK_SIZE (0x00998000)
(2) Assuming (1) is not an obstacle, how does one bootstrap a new system?
I was able to recompile the 'lisp' binary (using the internals.h file
that comes in the binry distribution), but the resulting binary
refuses to load the old core files, even without changing any of
the code or constants.
Core files only work with the "lisp" binary they were built with.
Here's the process I follow to bootstrap a new core file:
(1) Rebuild the lisp executable:
% cd lisp
% ln -s Config.sun4c_41 Config
% touch Depends
% gmake depend (i.e. gnu make)
% gmake
(2) Edit the pathnames in tools/compile-all, and run it. This uses
the existing CMU lisp to compile all the various parts of the system.
If you don't want PCL, Hemlock, CLM, etc., use -nocompile on the
command-line argument.
(3) Edit the pathnames in tools/mk-lisp, and run it. This makes the
new core file. Again, you can use command-line arguments to suppress
loading of pieces you don't want.
(4) Install the new lisp executable and core file in the appropriate
places.
-Sandra
From: Martin Cracauer
Subject: Re: Need help with CMUCL bootstrap (Re: CMUCL memory allocation bug ?)
Date:
Message-ID: <1995May26.114849.25655@wavehh.hanse.de>
·······@ICSI.Berkeley.EDU (Andreas Stolcke) writes:
>Is the boostrap procedure for CMUCL documented somewhere?
In the distribution area of CMUCL there is a document
"internals.ps". Alternativly, you get get the tex sources for this
from "documents.tar", subdir "internals". It is not very verbose.
I have a bit more info from a porting effort. Contact me if you need
it.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de>. No NeXTMail, please.
Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a
private address. At (netless) work programming in data analysis.
From: [Invalid-From-Line]
Subject: need help with cmucl bootstrap
Date:
Message-ID: <3q595g$9rd@ra.nrl.navy.mil>
In article <······························@functor.CS.Yale.Edu> ················@CS.Yale.Edu (Sandra Loosemore) writes:
> ·······@ICSI.Berkeley.EDU (Andreas Stolcke) writes:
>
> (1) Can I simply increase DYNAMIC_SPACE_SIZE and rebuild lisp, or will this
> break some built-in assumptions about memory layout etc.
>
> Yes, you can change these constants. Just make sure that the various
> memory areas defined in sparc-validate.h don't overlap each other.
> I've hacked up our local copy of CMU CL to give it a much bigger
> stack, for example:
>
> #define CONTROL_STACK_START (0xe1000000)
> #define CONTROL_STACK_SIZE (0x00998000)
>
...
>
> -Sandra
>
>
I had a problem a few months back with the SGI version of CMUCL
crashing on a large problem. I sent a message to cmucl-bugs:
[CMUCL 17f, SGI IRIX 5.2]
I have a large (I'm guessing >1GB of consing) problem I'm trying to run.
I get one of two errors, either:
set_auto_gc_trigger: tried to set gc trigger too high! (67113160)
[GC completed with 43,113,160 bytes retained and 20,849,984 bytes freed.]
[GC will next occur when at least 67,113,160 bytes are in use.]
Segmentation fault (core dumped)
or, from /usr/adm/SYSLOG:
Dec 20 17:51:49 4A:eutaw unix: WARNING: Process [lisp] 6618 generated
trap, but has signal 8 held or ignored
Dec 20 17:51:49 2A:eutaw unix: Process has been killed to prevent
infinite loop
... and got the folowing response:
Date: Wed, 21 Dec 1994 11:32:03 -0500
From: Rob MacLachlan <··············@ADDER.SLISP.CS.CMU.EDU>
There isn't any easy solution. Due to some problem with branch range on
the MIPS, we decided to limit the entire heap to a fraction of the address
space. If you are fairly close to fitting, then you might be able to get
things to work by putting stuff in static/read-only space using ext:purify.
Rob
Now, my problem looks exactly like the problem reported here by Andreas Stolcke
(except on the SGI instead of Sun). I checked, and mips_validate.h
has the constant DYNAMIC_SPACE_SIZE 0x04000000.
So is this the problem, or is it the branch range problem for the MIPS
that Rob MacLachlan said? (if the former, I'd try to rebuild CMUCL.)
Liam M. Healy