Hello group,
Summary: a heap overflow problem when running consequent (room) in
CMUCL.
Descripiton: I work with CMUCL 19d on linux. When I run (room) several
times, each consequent run takes more time, and produces a GC report
of a form
; [GC threshold exceeded with XXXX bytes in use. Commencing GC.]
; [GC completed with 166,344 bytes retained and YYYY bytes freed.]
; [GC will next occur when at least 12,166,344 bytes are in use.]
where numbers XXXX and YYYY are constantly incresing. Finally, after
11th run on my machine, I receive KERNEL:HEAP-OVERFLOW message.
Anybody has any clue? Seems to be a bug for me.
Regards,
Victor.
PS. On sbcl 1.0.5, everything works just fine.
PPS. I've applied both patch-001 and patch-002 for CMUCL 19d - that
still doesn't change the (room) behaviour.
Appendix: detailed information
$ uname -a
Linux victoria 2.6.20-15-server #2 SMP Sun Apr 15 07:41:34 UTC 2007
i686 GNU/Linux
(Ubuntu 7.04)
$ lisp -noinit
CMU Common Lisp 19d (19D), running on victoria
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2006-11-15 20:43:04-06:00 on lorien
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (loop for i from 1 to 11 do (room))
Dynamic Space Usage: 116,296 bytes (out of 512 MB).
Read-Only Space Usage: 21,662,224 bytes (out of 256 MB).
Static Space Usage: 2,958,176 bytes (out of 256 MB).
Control Stack Usage: 868 bytes (out of 128 MB).
Binding Stack Usage: 96 bytes (out of 128 MB).
The current dynamic space is 0.
Garbage collection is currently enabled.
Breakdown for dynamic space:
50,384 bytes for 6,298 cons objects.
36,488 bytes for 980 simple-string-type objects.
16,376 bytes for 339 instance objects.
7,112 bytes for 882 bignum objects.
6,680 bytes for 31 simple-array-unsigned-byte-32-type
objects.
13,960 bytes for 1,081 other objects.
131,000 bytes for 9,611 dynamic objects (space total.)
[... skipped ...]
Dynamic Space Usage: 183,112 bytes (out of 512 MB).
Read-Only Space Usage: 21,662,224 bytes (out of 256 MB).
Static Space Usage: 2,958,176 bytes (out of 256 MB).
Control Stack Usage: 868 bytes (out of 128 MB).
Binding Stack Usage: 96 bytes (out of 128 MB).
The current dynamic space is 0.
Garbage collection is currently enabled.
; [GC threshold exceeded with 471,614,736 bytes in use. Commencing
GC.]
; [GC completed with 166,960 bytes retained and 471,447,776 bytes
freed.]
; [GC will next occur when at least 12,166,960 bytes are in use.]
Breakdown for dynamic space:
117,851,960 bytes for 14,731,495 sap objects.
117,815,472 bytes for 14,726,929 bignum objects.
129,312 bytes for 5,357 other objects.
235,796,744 bytes for 29,463,781 dynamic objects (space total.)
Dynamic Space Usage: 183,744 bytes (out of 512 MB).
Read-Only Space Usage: 21,662,224 bytes (out of 256 MB).
Static Space Usage: 2,958,176 bytes (out of 256 MB).
Control Stack Usage: 868 bytes (out of 128 MB).
Binding Stack Usage: 96 bytes (out of 128 MB).
The current dynamic space is 0.
Garbage collection is currently enabled.
*A2 gc_alloc_new_region failed, nbytes=8.
CMUCL has run out of dynamic heap space (512 MB).
You can control heap size with the -dynamic-space-size commandline
option.
Imminent dynamic space overflow has occurred:
Only a small amount of dynamic space is available now. Please note
that you will be returned to the Top-Level without warning if you run
out of space while debugging.
Heap (dynamic space) overflow
[Condition of type KERNEL:HEAP-OVERFLOW]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(KERNEL:DYNAMIC-SPACE-OVERFLOW-WARNING-HIT)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no
longer exists:
target:code/interr.lisp.
0]
* Madhu <·······@meer.net> <··············@robolove.meer.net> :
| * Victor Kryukov <························@e51g2000hsg.XXX> :
| | Summary: a heap overflow problem when running consequent (room) in
| | CMUCL.
| |
| | Descripiton: I work with CMUCL 19d on linux. When I run (room) several
| | times, each consequent run takes more time, and produces a GC report
| | of a form
| [...]
| | where numbers XXXX and YYYY are constantly incresing. Finally, after
| | 11th run on my machine, I receive KERNEL:HEAP-OVERFLOW message.
| |
| | Anybody has any clue? Seems to be a bug for me.
|
| There seems to be a known bug. My build (19C) of 2006-03-31 does not
| suffer this problem, but a of 2006-08 sources does.
This seems to be a result of the commit to room.lisp from:
> revision 1.36
> date: 2006-07-20 16:19:35 +0000; author: rtoy; state: Exp; lines: +151 -1
> Port sbcl's changes to room to handle gencgc allocation better.
However: (loop for i from 1 to 11 do (princ i) (terpri) (room) (gc :full t))
works OK.
Incidentally there was a similar earlier problem which was fixed in 04 --
> revision 1.33
> date: 2004-06-18 17:44:28 +0000; author: rtoy; state: Exp; lines: +14 -12
> Less consy ROOM function. Also fixes an issue where ROOM appeared to
> cause garbage to be retained with gencgc on x86 (but not sparc),
> eventually causing an out-of-heap error.
| There was a recent commit, which I think speaks of this problem:
|> Date: Wed, 2 May 2007 12:50:14 -0400 (EDT)
|> Modified Files: purify.c
[snip]
[I think this may not be directly related to the problem you are seeing]
--
Madhu