From: William H. N. <wil...@ai...> - 2003-07-18 18:41:22
|
I have now gotten failures like ; compiling top level form: fatal error encountered in SBCL pid 6844: GC invariant lost, file "gc-common.c", line 375 There's no LDB in this build; exiting. from two recent versions of SBCL (0.8.1.43 on one machine, .39-I-think on the other) compiling some of my application code. The same application code builds and runs fine on 0.8.1.29. 0.8.1.43 has just finished hosting its own make.sh, so evidently not just any compilation suffices to cause the crash. I will probably get around to bisection search for a useful test case sometime when I'm feeling too groggy for regular programming, likely sometime this weekend. Meanwhile, even without a proper test case I thought it might be useful to mention it here, in case someone else notices similar symptoms and wonders whether it's a problem on their machine or something in SBCL which should be reported here. -- William Harold Newman <wil...@ai...> "When something becomes stable enough for you to use it yourself without it crashing, and you don't know how to make it crash, you should release it (with lots of warnings)." -- Hans Reiser, in slashdot interview PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2003-07-18 20:11:22
|
On Fri, Jul 18, 2003 at 01:16:19PM -0500, William Harold Newman wrote: > I have now gotten failures like > ; compiling top level form: > fatal error encountered in SBCL pid 6844: > GC invariant lost, file "gc-common.c", line 375 > There's no LDB in this build; exiting. > from two recent versions of SBCL (0.8.1.43 on one machine, .39-I-think > on the other) compiling some of my application code. The same > application code builds and runs fine on 0.8.1.29. After seeing increasingly weird patterns of behavior as I rebuilt things trying to make a smaller test case, it finally sunk in that maybe it was just a .fasl file format incompatibility. And lo! once I rebuilt everything FASLish from scratch, the problem went away, at least on the one computer I've tried it on so far. So my working hypothesis is that sometime between .29 and .39 -- maybe in the VECTOR NIL patch? -- something changed in a binarily incompatible way which nuked my code, and so * I'll try to make sure that +FASL-FILE-VERSION+ gets incremented soon (even though 42 is of course a particularly traditional number:-). * I'll probably tweak my install.sh script wrapper so that it deletes all my library .fasls, since I know from experience that it's keeping +F-F-V+ up to date in minor releases is error-prone and tedious. (My wrapper used to do this until the functionality rotted with the changes associated with the module system.) -- William Harold Newman <wil...@ai...> "When something becomes stable enough for you to use it yourself without it crashing, and you don't know how to make it crash, you should release it (with lots of warnings)." -- Hans Reiser, in slashdot interview PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Christophe R. <cs...@ca...> - 2003-07-18 20:30:38
|
William Harold Newman <wil...@ai...> writes: > On Fri, Jul 18, 2003 at 01:16:19PM -0500, William Harold Newman wrote: > So my working hypothesis is that sometime between .29 and .39 -- maybe > in the VECTOR NIL patch? -- something changed in a binarily > incompatible way which nuked my code, and so Oh, yes... in the refactorings around specialized arrays, I will probably have renumbered just about every array widetag. That would cause GC problems, yes :-) > * I'll try to make sure that +FASL-FILE-VERSION+ gets incremented soon > (even though 42 is of course a particularly traditional number:-). I've even tried to maintain a certain amount of 42ness in improving SB-MOP:CLASS-PROTOTYPE; my only regret is that 2^42 will not be a bignum in any eventual 64-bit port :-) 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) |