From: Benjamin Lambert <benlambert@cm...> - 2006-05-05 21:17:56
I encountered some strange behavior with save-lisp-and-die. I'm not
sure if I'll be able to give enough information to identify the problem,
but I'll give it a shot. The first paragraph below describes the
previous problem I had (which now seems to be fixed but led up to the
current problem), but the second paragraph is a problem I'm looking for
some help with.
First of all, I'm running on a 64-bit AMD machine with 8GB of RAM. I'm
doing some very memory intensive experiments that use a few gigs of RAM
(including many large hashtables). At first I was using the SBCL 0.9.4
binary but I was getting "mprotect: cannot allocate memory" errors after
the process got up to around 1.5Gigs of RAM. I searched in the mailing
list archive and found the suggestion to change gencgc-page-size to 32K
which was suggested for a very similar sounding problem (involving
mprotect and munmap or something like that). So, I downloaded 0.9.12,
increased that parameter to 32k and recompiled with this change to
;(def!constant gencgc-page-size 4096)
(def!constant gencgc-page-size 32768)
That seemed to fix the mprotect problem and it was able to allocate the
memory I needed. Once I had all my data structures loaded (which takes
a while), I tried to do a save-lisp-and-die so I wouldn't have to load
it all again. It did not signal an error and at first seemed to work,
but the image it produced was only 557072 bytes (557K, not several gigs
as I expected). You can see the output from save-lisp-and-die pasted
below. The interesting thing is that the number of bytes it reports to
have written from the dynamic space is negative. I wonder if this could
indicate that there's a 32 bit counter in that function somewhere...
Another thought I had about why this might be happening is that perhaps
there is some 2GB max file size limit in SBCL, the OS (Fedora, I
believe), or the filesystem. I still have the 557K core file if that
would help to figure out that problem. I'll also paste the error I get
when I try to load the 557K core file with "sbcl --core" (which includes
an mmap error)
* (save-lisp-and-die "DBLP-15k-wDS.image" :purify nil)
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into /home/benlambert/DBLP/DBLP-15k-wDS.image:
writing 1744 bytes from the read-only space at 0x20000000
writing 2272 bytes from the static space at 0x40000000
writing -2067824640 bytes from the dynamic space at 0x1000000000
DBLP> sbcl --core DBLP-15k-wDS.image
This is SBCL 0.9.12, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
mmap: Invalid argument
fatal error encountered in SBCL pid 3900:
unexpected mmap(..) failure
The system is too badly corrupted or confused to continue at the Lisp
level. If the system had been compiled with the SB-LDB feature, we'd drop
into the LDB low-level debugger now. But there's no LDB in this build, so
we can't really do anything but just exit, sorry.
Benjamin Lambert, Graduate Student of Computer Science
Carnegie Mellon University - Language Technologies Institute
Office: 3612 Newell-Simon, Phone# 412-268-4083, Fax# 412-268-6298