From: Nikodemus S. <nik...@ra...> - 2008-05-29 09:53:44
|
but you can workaround the bug by changing the defconstant at the top of swank.lisp to defvars. Fix coming up later. Cheers -- and sorry about that, -- Nikodemus |
From: Chavdar I. <ci...@gm...> - 2008-05-29 13:09:12
|
2008/5/29 Nikodemus Siivola <nik...@ra...>: > but you can workaround the bug by changing the defconstant at the top > of swank.lisp to defvars. Fix coming up later. Changing only the first defconstant to defvar failed; changing both sort of worked, but with the following: ... fasl stack not empty when it should be This is probably a bug in SBCL itself. (Alternatively, SBCL might have been corrupted by bad user code, e.g. by an undefined Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe Lisp code; or there might be a bug in the OS or hardware that SBCL is running on.) If it seems to be a bug in SBCL itself, the maintainers would like to know about it. Bug reports are welcome on the SBCL mailing lists, which you can find at <http://sbcl.sourceforge.net/>. [Condition of type SB-INT:BUG] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SB-INT:BUG "fasl stack not empty when it should be")[:EXTERNAL] 1: (SB-FASL::FOP-VERIFY-EMPTY-STACK) 2: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file /home/ci/.slime/fasl/2008-04-17/sbcl-1.0.17.5-unix-x86/contrib/swank-arglists.fasl" {629CFE29}>) 3: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 4: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file /home/ci/.slime/fasl/2008-04-17/sbcl-1.0.17.5-unix-x86/contrib/swank-arglists.fasl" {629CFE29}> NIL #<unavailable argument>) 5: ((FLET SB-FASL::LOAD-STREAM) #<SB-SYS:FD-STREAM for "file /home/ci/.slime/fasl/2008-04-17/sbcl-1.0.17.5-unix-x86/contrib/swank-arglists.fasl" {629CFE29}>) 6: (LOAD #P"/home/ci/.slime/fasl/2008-04-17/sbcl-1.0.17.5-unix-x86/contrib/swank-arglists.fasl")[:EXTERNAL] 7: (REQUIRE :SWANK-ARGLISTS (#P"/home/ci/.slime/fasl/2008-04-17/sbcl-1.0.17.5-unix-x86/contrib/swank-arglists.fasl")) 8: (SWANK:SWANK-REQUIRE (:SWANK-FUZZY :SWANK-FANCY-INSPECTOR :SWANK-ARGLISTS) NIL) 9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:SWANK-REQUIRE (QUOTE (:SWANK-FUZZY :SWANK-FANCY-INSPECTOR :SWANK-ARGLISTS))) #<NULL-LEXENV>) 10: ((LAMBDA NIL)) 11: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {6285CCB5}>) 12: ((LAMBDA NIL)) 13: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {632C5055}>) 14: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {626F8059}> #<CLOSURE (LAMBDA NIL) {6285B42D}>) 15: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {626F8059}> #<FUNCTION (LAMBDA NIL) {632C5055}>) 16: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {626F8059}>) 17: (SWANK::PROCESS-AVAILABLE-INPUT #<SB-SYS:FD-STREAM for "a socket" {626F7551}> #<CLOSURE (LAMBDA NIL) {6285B41D}>) 18: ((FLET SWANK::HANDLER)) 19: ((LAMBDA (SWANK-BACKEND::_)) #<unused argument>) 20: (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL) 21: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL) 22: (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 23: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {61680781}>) 24: (SB-IMPL::INPUT-CHAR/ASCII #<SB-SYS:FD-STREAM for "standard input" {61680781}> NIL #:EOF-OBJECT) 25: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {61680781}> NIL #:EOF-OBJECT #<unused argument>) 26: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {600BD011}> NIL #:EOF-OBJECT #<unused argument>) 27: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {600BD011}> NIL (NIL) T) 28: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {600BD011}> NIL (NIL) NIL) 29: (READ #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {600BD011}> NIL (NIL) NIL) 30: (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {600BD011}> #<unavailable argument>) 31: (SB-IMPL::REPL-FUN NIL) 32: (SB-IMPL::REPL-FUN NIL)[:EXTERNAL] 33: ((LAMBDA NIL)) 34: ((LAMBDA NIL))[:EXTERNAL] 35: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA NIL) {616C2EE5}>) 36: (SB-IMPL::TOPLEVEL-REPL NIL) 37: (SB-IMPL::TOPLEVEL-INIT) 38: ((LABELS SB-IMPL::RESTART-LISP)) > > Cheers -- and sorry about that, > > -- Nikodemus > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > This is on i386 NetBSD-current (another story...) -- ---------------------------------------------------------------- /dev/random says: I always lie. In fact, I'm lying to you right now! ---------------------------------------------------------------- Chavdar Ivanov | Talbot Way, Small Heath Business Park Delcam UK | Birmingham B10 0HJ, United Kingdom Customer Support | (+44)121-6831014 ---------------------------------------------------------------- |
From: Attila L. <att...@gm...> - 2008-05-29 13:27:47
|
> ... > fasl stack not empty when it should be > This is probably a bug in SBCL itself. (Alternatively, SBCL > might have been corrupted by bad user code, e.g. by an undefined i _think_ this is unrelated. i've seen this a few times and i have a vague suspicion that it happens due to half-written (corrupt) fasl's. maybe writing the fasl header magic constant at the very end of the fasl writing procedure would help with this? kind of like a two-phase transaction commit bit. -- attila |
From: Nikodemus S. <nik...@ra...> - 2008-05-29 13:36:05
|
On Thu, May 29, 2008 at 4:09 PM, Chavdar Ivanov <ci...@gm...> wrote: > 2008/5/29 Nikodemus Siivola <nik...@ra...>: >> but you can workaround the bug by changing the defconstant at the top >> of swank.lisp to defvars. Fix coming up later. Should be fixed in 1.0.17.6. > Changing only the first defconstant to defvar failed; changing both > sort of worked, but with the following: > > ... > fasl stack not empty when it should be > This is probably a bug in SBCL itself. (Alternatively, SBCL > might have been corrupted by bad user code, e.g. by an undefined > Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers > from alien code or from unsafe Lisp code; or there might be a > bug in the OS or hardware that SBCL is running on.) If it seems > to be a bug in SBCL itself, the maintainers would like to know > about it. Bug reports are welcome on the SBCL mailing lists, > which you can find at <http://sbcl.sourceforge.net/>. > [Condition of type SB-INT:BUG] Did you reload stuff into an existing image, or did you 1. quit Slime, 2. edit the file, 3. nuke the fasls, 4. realod? The fasl-stack-not-empty is usually a manifestation of bug #332 -- which fits, because IIRC Slime does a bit of violence to pretty printer structres. (Bug below for reference.) Cheers, -- Nikodemus 332: "fasl stack inconsistency in structure redefinition" (reported by Tim Daly Jr sbcl-devel 2004-05-06) Even though structure redefinition is undefined by the standard, the following behaviour is suboptimal: running (defun stimulate-sbcl () (let ((filename (format nil "/tmp/~A.lisp" (gensym)))) ;;create a file which redefines a structure incompatibly (with-open-file (f filename :direction :output :if-exists :supersede) (print '(defstruct astruct foo) f) (print '(defstruct astruct foo bar) f)) ;;compile and load the file, then invoke the continue restart on ;;the structure redefinition error (handler-bind ((error (lambda (c) (continue c)))) (load (compile-file filename))))) (stimulate-sbcl) and choosing the CONTINUE restart yields the message debugger invoked on a SB-INT:BUG in thread 27726: fasl stack not empty when it should be |
From: Chavdar I. <ci...@gm...> - 2008-05-29 13:57:14
|
2008/5/29 Nikodemus Siivola <nik...@ra...>: > On Thu, May 29, 2008 at 4:09 PM, Chavdar Ivanov <ci...@gm...> wrote: >> 2008/5/29 Nikodemus Siivola <nik...@ra...>: >>> but you can workaround the bug by changing the defconstant at the top >>> of swank.lisp to defvars. Fix coming up later. > > Should be fixed in 1.0.17.6. > >> Changing only the first defconstant to defvar failed; changing both >> sort of worked, but with the following: >> >> ... >> fasl stack not empty when it should be >> This is probably a bug in SBCL itself. (Alternatively, SBCL >> might have been corrupted by bad user code, e.g. by an undefined >> Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers >> from alien code or from unsafe Lisp code; or there might be a >> bug in the OS or hardware that SBCL is running on.) If it seems >> to be a bug in SBCL itself, the maintainers would like to know >> about it. Bug reports are welcome on the SBCL mailing lists, >> which you can find at <http://sbcl.sourceforge.net/>. >> [Condition of type SB-INT:BUG] > > Did you reload stuff into an existing image, or did you 1. quit Slime, > 2. edit the file, 3. nuke the fasls, 4. realod? When your message arrived, I was just about to press "Send" with the message saying that all is OK after I nuked all the .fasl files from ~/.slime. > > The fasl-stack-not-empty is usually a manifestation of bug #332 -- > which fits, because IIRC Slime does a bit of violence to pretty > printer structres. > (Bug below for reference.) > > Cheers, > > -- Nikodemus > > 332: "fasl stack inconsistency in structure redefinition" > (reported by Tim Daly Jr sbcl-devel 2004-05-06) > Even though structure redefinition is undefined by the standard, the > following behaviour is suboptimal: running > (defun stimulate-sbcl () > (let ((filename (format nil "/tmp/~A.lisp" (gensym)))) > ;;create a file which redefines a structure incompatibly > (with-open-file (f filename :direction :output :if-exists :supersede) > (print '(defstruct astruct foo) f) > (print '(defstruct astruct foo bar) f)) > ;;compile and load the file, then invoke the continue restart on > ;;the structure redefinition error > (handler-bind ((error (lambda (c) (continue c)))) > (load (compile-file filename))))) > (stimulate-sbcl) > and choosing the CONTINUE restart yields the message > debugger invoked on a SB-INT:BUG in thread 27726: > fasl stack not empty when it should be > -- ---------------------------------------------------------------- /dev/random says: I always lie. In fact, I'm lying to you right now! ---------------------------------------------------------------- Chavdar Ivanov | Talbot Way, Small Heath Business Park Delcam UK | Birmingham B10 0HJ, United Kingdom Customer Support | (+44)121-6831014 ---------------------------------------------------------------- |
From: F. <fa...@gm...> - 2008-05-29 22:34:07
|
2008/5/29 Attila Lendvai <att...@gm...>: > maybe writing the fasl header magic constant at the very end of the > fasl writing procedure would help with this? kind of like a two-phase > transaction commit bit. A magic constant is good, but could occasionally be confused with random data. Since we're talking about files, one way to detect complete files without fail is to have a length field at the beginning of the file, initially full of zeroes, and overwritten with the actual length when you're done with the fasl (and no, having it at the end doesn't work at well). Of course, the real solution to not leaving incomplete FASLs around is to atomically supersede the FASL when you close the stream from a temporary file with a different name used while the file is open. Why doesn't SBCL provide and use such a mode of with-open-file? This would solve a lot of problems with interrupted compiler (not the first time I suggest it). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Thinking is the hardest work there is, which is probably the reason why so few engage in it. -- Henry Ford |
From: Nikodemus S. <nik...@ra...> - 2008-05-30 07:29:27
|
On Fri, May 30, 2008 at 1:34 AM, Faré <fa...@gm...> wrote: > Of course, the real solution to not leaving incomplete FASLs around is > to atomically supersede the FASL when you close the stream from a > temporary file with a different name used while the file is open. Why > doesn't SBCL provide and use such a mode of with-open-file? This would This is currently done. The fasl-stack-empty has nothing to do with truncated fasl files. Cheers, -- Nikodemus |
From: Attila L. <att...@gm...> - 2008-06-04 20:37:14
|
> > Of course, the real solution to not leaving incomplete FASLs around is > > to atomically supersede the FASL when you close the stream from a > > temporary file with a different name used while the file is open. Why > > doesn't SBCL provide and use such a mode of with-open-file? This would > > > This is currently done. The fasl-stack-empty has nothing to do with > truncated fasl files. -rw-r--r-- 1 ati admin 253 2008-06-04 22:27 asdf.fasl -rw-r--r-- 1 ati admin 255 2008-06-04 22:27 grovel.fasl it's basically only the fasl header because the first expressions resulted in the errors. seemingly subsequent 'load-op's happily load these fasls which leads to missing declaration errors. this led me to write my first mail about this. now that i've seen this happening again, i went on checking out the fasls, that you can see above. afaicr, i was running sbcl from a shell to build a core file. then sbcl's debugger came up, where pressed C-d twice to quit to the repl. but back to the jungle fight, now... :) hth, -- attila |
From: Nikodemus S. <nik...@ra...> - 2008-06-05 08:50:54
|
On Wed, Jun 4, 2008 at 11:37 PM, Attila Lendvai <att...@gm...> wrote: >> This is currently done. The fasl-stack-empty has nothing to do with >> truncated fasl files. > afaicr, i was running sbcl from a shell to build a core file. then > sbcl's debugger came up, where pressed C-d twice to quit to the repl. So, I was wrong on both counts: SBCL used to leave fasls lying around if you unwound from COMPILE-FILE, and stupidly wrote even an additional sanity check for fasl-stack emptiness at the end of those fasls. Sorry about that. 1.0.17.27 deletes the incomplete fasl in case of an unwind, and doesn't write the tail-end checks in either. Cheers, -- Nikodemus |
From: F. <fa...@gm...> - 2008-06-05 14:48:05
|
2008/6/5 Nikodemus Siivola <nik...@ra...>: > So, I was wrong on both counts: SBCL used to leave fasls lying around > if you unwound from COMPILE-FILE, and stupidly wrote even an > additional sanity check for fasl-stack emptiness at the end of those > fasls. Sorry about that. At the cost of repeating myself: could we not instead open a fasl under a temporary name and *atomically* rename it to the destination name on successful close? This could either be the default behavior of :supersede, or a different sbcl-specific option of with-open-file. I could do the coding, if needed. Or we could reuse RmK's code. But importantly, get some kind of general approval (or absence of shouting against) before to commit it. > 1.0.17.27 deletes the incomplete fasl in case of an unwind, and > doesn't write the tail-end checks in either. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] We don't want tradition. We want to live in the present and the only history that is worth a tinker's dam is the history we make today. -- Henry Ford |
From: Nikodemus S. <nik...@ra...> - 2008-06-05 15:55:23
|
On Thu, Jun 5, 2008 at 5:48 PM, Faré <fa...@gm...> wrote: > At the cost of repeating myself: could we not instead open a fasl > under a temporary name and *atomically* rename it to the destination > name on successful close? This could either be the default behavior of > :supersede, or a different sbcl-specific option of with-open-file. I am not opposed to going that route. I don't exactly remember where the discussion about W-O-F using renaming to provide atomicity ended up, but at any rate using such an approach for COMPILE-FILE specifically, even if it not used for W-O-F generally would be fine by me. That said, the problem with the code prior to 1.0.17.27 (which does the deletion "properly" -- not atomically, but doesn't still) was a bad initialization value to an abort flag inside COMPILE-FILE, which lead the cleanup forms (including the eventual CLOSE) to be called with :ABORT NIL if the compilation ended up unwinding. ...this is to say that even if the code had been using a rename-when-complete approach, it would have still produced these same broken fasls. > I could do the coding, if needed. Or we could reuse RmK's code. But > importantly, get some kind of general approval (or absence of shouting > against) before to commit it. I can stick this on my TODO. Cheers, -- Nikodemus |