John Klein <jk271828@...> writes:
> Just to see if I understand where things stand...
>
> so ARRAY-TOTAL-SIZE-LIMIT is much smaller than the 10^24 elements in my
> array. And SBCL shouldn't die when allocating an excessively big
> array, I think.
$ sbcl
This is SBCL 0.8.9.58, 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.
* (> array-total-size-limit (* 4096 4096))
T
So SBCL should be OK with the array you are trying to make.
> > * (let ((f (make-array '(4096 4096) :initial-element 1d0)))
> > (= (aref f 10 11) 99d0))
>
> OK, but I _think_ this makes an array of 32 bit pointers pointing
> to the same boxed double float. So I think it is half as big as the
> 'double-float array.
I think you are correct. I'm going to try what you were doing with a
MUCH smaller 2d array. I don't want to thrash my machine to death in
system calls ;-)
* (let ((f (make-array '(10 10) :element-type 'double-float
:initial-element 1D0)))
(= (aref f 7 8) 99d0))
NIL
> With OpenMCL I understand the problem - the array is simply too big. But with
> SBCL it looks like a bug - in 0.8.9 the memory gets trashed for the next
> GC, not immediately. Also, it seems to be triggered if
> I try to allocate two smaller arrays - this is how I originally hit the
> problem.
I see. Does this work for you?
* (loop for i from 1 to 100000 do
(let ((f (make-array 4096 :element-type 'double-float)))
(= (aref f 10) 1d0)))
NIL
I'm going to try your original again.
* (let ((f (make-array '(4096 4096) :element-type 'double-float)))
(= (aref f 10 11) 99d0))
set_auto_gc_trigger: tried to set gc trigger too high! (0x807e37c)
fatal error encountered in SBCL pid 1299:
lost
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.
OK, it's not fixed in the latest version yet.
This is interesting:
* (progn (gc-off)
(let ((f (make-array '(4096 4096) :element-type 'double-float)))
(= (aref f 10 11) 99d0))
(gc-on)
(gc))
fatal error encountered in SBCL pid 1304:
GC invariant lost, file "gc-common.c", line 616
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.
We get a line number even without LDB enabled. I find this function
there:
static int
scav_other_pointer(lispobj *where, lispobj object)
{
lispobj first, *first_pointer;
gc_assert(is_lisp_pointer(object));
/* Object is a pointer into from space - not FP. */
first_pointer = (lispobj *) native_pointer(object);
first = (transother[widetag_of(*first_pointer)])(object);
if (first != object) {
set_forwarding_pointer(first_pointer, first);
#ifdef LISP_FEATURE_GENCGC
*where = first;
#endif
}
#ifndef LISP_FEATURE_GENCGC
*where = first;
#endif
gc_assert(is_lisp_pointer(first));
gc_assert(!from_space_p(first));
return 1;
}
I think it is blowing up on that last gc_assert.
For my next build, I'm going to go ahead and enable the LDB. This is
an interesting problem. While the code asks a lot from the system,
it certainly should be managable.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
|