From: Roman A. B. <ro...@pa...> - 2004-05-06 00:53:51
|
I've looked through the BUGS file in the SBCL 0.8.10 tarfile & didn't seem to find the following reported. I asked on #lisp about it and someone had a deja-vu & suggested "that /might/ be compiler data structures growing without bounds". Cheers, Roman ======================================================= I'm running gentoo linux 2.6.4-gentoo-r1 on an AMD XP 1800+ with 1 Gig of RAM. I've installed both CMUCL (CMU Common Lisp CVS release-18e-branch + minimal debian patches) & SBCL 0.8.8 To test them, I tried running the code: http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/genetic/gp/systems/koza/koza_gp.cl by loading it & running the function (test-gpp). CMUCL runs to completion. SBCL croaks with: "Argh! gc_find_free_space failed (first_page), nbytes=56." So, I downloaded SBCL 0.8.10 & rebuilt sbcl with a customize-target-features.lisp file containing: (lambda (list) (flet ((enable (x) (pushnew x list)) (disable (x) (setf list (remove x list)))) (enable :sb-thread) (enable :sb-futex) list)) After loading the program koza_gp.cl & running (test-gpp) the eventual error is: Generation 5: Average standardized-fitness = 60.62. The best individual program of the population had a standardized fitness measure of 34.0 and 4 hits. It was: (IFX (GOW) (IFY (GOW) (GON) (GON)) (IFY (IFX (GON) (IFX (GOW) (GOW) (GOW)) (GOS)) (IFY (IFX (IFX (GON) (GOS) (GON)) (IFY (GOS) (GOW) (GOE)) (GOE)) (IFX (IFY (GOW) (GOE) (GOW)) (IFX (GOE) (GOS) (GOW)) (GOE)) (IFY (GON) (GOE) (GOS))) Argh! gc_find_free_space failed (first_page), nbytes=40. Gen Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age 0: 0 0 0 0 0 0 0 2000000 0 0 0.0000 1: 0 0 0 0 0 0 0 2000000 0 0 0.0000 2: 0 0 0 0 0 0 0 2000000 0 0 0.0000 3: 0 0 0 0 0 0 0 2000000 0 0 0.0000 4: 60243 15318 0 0 0 309139696 358160 197482416 0 1 1.4854 5: 41770 13068 673 0 104 227072024 301032 2000000 0 0 0.0000 6: 0 0 0 0 0 0 0 0 0 0 0.0000 Total bytes allocated=536211720 fatal error encountered in SBCL pid 8926 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. |
From: Christophe R. <cs...@ca...> - 2004-05-06 22:10:22
|
"Roman A. Brenes" <ro...@pa...> writes: > Argh! gc_find_free_space failed (first_page), nbytes=40. > Gen Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age > 4: 60243 15318 0 0 0 309139696 358160 197482416 0 1 1.4854 > 5: 41770 13068 673 0 104 227072024 301032 2000000 0 0 0.0000 > Total bytes allocated=536211720 Well, the SBCL heap, I'm afraid, would appear to be 537 x 10^6 bytes, so given that the system believes at this point that it has about that much live data, your crash would appear to be, erm, fair enough. However, given that other lisps run this to completion, it may be that data that sbcl believes is live isn't actually. This might be a result of garbage collector conservatism, or could be some other bug in the garbage collector. It would be nice if you could find a suitable point, maybe between generations, and insert explicit calls of the form (sb-ext:gc :full t) to see if you can identify anywhere where data may be being retained erroneously. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |