heap exhausted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
New
|
Undecided
|
Unassigned |
Bug Description
This is SBCL on a Mac running macOS 10.14.3
I'm running some kind of MAPPEND function three times in a row. Then the heap is exhausted. The results retained in the listener shouldn't be too large. The intermediate lists created by the test are 5000 x 5000 elements. Should the GC be able to reclaim the memory?
bash-3.2$ sbcl
This is SBCL 1.5.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://
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.
* (setf *print-length* 40)
(defun mappend (function lists)
(loop with arg = (make-list (length lists))
and lists1 = (make-array (length lists) :initial-contents lists)
while (aref lists1 0)
do (loop for i below (length lists1)
do (setf (first l) (first (aref lists1 i))))
append (funcall function arg)
do (loop for i below (length lists1) do (pop (aref lists1 i)))))
(defun test (n)
(let ((l (loop for i below n collect (loop repeat n collect i))))
(time (mappend (lambda (e) (list :a (car e) :b (cadr e))) l))))
40
* MAPPEND
* TEST
* (test 5000)
Evaluation took:
0.342 seconds of real time
0.342000 seconds of total run time (0.341912 user, 0.000088 system)
100.00% CPU
1,091,655,274 processor cycles
737,168 bytes consed
(:A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B
1 :A 0 :B 1 :A 0 :B 1 ...)
* (test 5000)
Evaluation took:
0.335 seconds of real time
0.335355 seconds of total run time (0.335271 user, 0.000084 system)
100.00% CPU
1,070,441,555 processor cycles
764,304 bytes consed
(:A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B 1 :A 0 :B
1 :A 0 :B 1 :A 0 :B 1 ...)
* (test 5000)
Heap exhausted during garbage collection: 0 bytes available, 16 requested.
Gen Boxed Unboxed LgBox LgUnbox Pin Alloc Waste Trig WP GCs Mem-age
0 0 0 0 0 0 0 0 10737418 0 0 0.0000
1 16397 1 0 0 7 537162864 166800 332832602 16398 1 1.3994
2 15548 42 0 0 14 510702224 150896 2000000 15590 0 0.2263
3 0 0 0 0 0 0 0 2000000 0 0 0.0000
4 0 0 0 0 0 0 0 2000000 0 0 0.0000
5 0 0 0 0 0 0 0 2000000 0 0 0.0000
6 449 220 64 47 0 24788416 770624 2000000 780 0 0.0000
7 0 0 0 0 0 0 0 2000000 0 0 0.0000
Total bytes allocated = 1072653504
GC control variables:
*GC-INHIBIT* = true
*GC-PENDING* = true
*STOP-
fatal error encountered in SBCL pid 4747(tid 0xf4af5c0):
Heap exhausted, game over.
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
For N = 5000, the list of lists L is ~25 million cons cells, occupying about 400M bytes of memory (on X86-64). If I recall correctly, the default build for sbcl has a maximum heap size of 500M. So it shouldn't be surprising you've run out of memory here, since GC needs some room for copying.
You aren't seeing this because your call to TIME does not include the loops where you are building L.
You can rebuild sbcl with a large heap size by specifying the --dynamic- space-size argument in the build script.