
Hello Peter, i just gave the newest sbcl source package a try - here's the outcome (stderror): (SB-PCL::FSC-INSTANCE-WRAPPER SB-PCL::I2)) ; --> LET* MULTIPLE-VALUE-BIND LET ; ==> ; (SB-KERNEL:%SET-FUNCALLABLE-INSTANCE-LAYOUT #:G159 #:G158) ; ; caught STYLE-WARNING: ; #S(SIMPLE-STYLE-WARNING ; :ACTUAL-INITARGS (FORMAT-CONTROL undefined ~(~A~): ~S ; FORMAT-ARGUMENTS ; (FUNCTION ; % SET-FUNCALLABLE-INSTANCE-LAYOUT)) ; :ASSIGNED-SLOTS NIL) ; in: DEFUN SET-WRAPPER ; (SETF (SB-PCL::FSC-INSTANCE-WRAPPER SB-PCL::INST) SB-PCL::NEW) ; --> LET* MULTIPLE-VALUE-BIND LET ; ==> ; (SB-KERNEL:%SET-FUNCALLABLE-INSTANCE-LAYOUT #:G129 #:G128) ; ; caught STYLE-WARNING: ; #S(SIMPLE-STYLE-WARNING ; :ACTUAL-INITARGS (FORMAT-CONTROL undefined ~(~A~): ~S ; FORMAT-ARGUMENTS ; (FUNCTION ; % SET-FUNCALLABLE-INSTANCE-LAYOUT)) ; :ASSIGNED-SLOTS NIL) ; ; caught STYLE-WARNING: ; #S(SIMPLE-STYLE-WARNING ; :ACTUAL-INITARGS (FORMAT-CONTROL ; ~:[This ~(~A~) is~;These ~(~A~)s are~] undefined:~ ; ~% ~{~<~% ~1:;~S~>~^ ~} ; FORMAT-ARGUMENTS ; (NIL FUNCTION (% SET-FUNCALLABLE-INSTANCE-LAYOUT))) ; :ASSIGNED-SLOTS NIL) ; ; compilation unit finished ; caught 3 STYLE-WARNING conditions fatal error encountered in SBCL pid 24834: GC invariant lost, file "gc-common.c", line 190 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. make: *** [build-arch-stamp] Error 1 pbuilder: Failed autobuilding of package The last output from stdout as well: ; SYS:SRC;PCL;INIT.FASL.NEWEST written ; compilation finished in 0:00:06 ; compiling file "/tmp/buildd/sbcl-0.9.5.9/src/pcl/std-class.lisp" (written 23 SEP 2005 01:00:55 PM): ; compiling (IN-PACKAGE "SB-PCL") ; compiling (DEFMETHOD SLOT-ACCESSOR-FUNCTION ...) ; compiling (DEFMETHOD (SETF SLOT-ACCESSOR-FUNCTION) ...) ; compiling (DEFCONSTANT +SLOTD-READER-FUNCTION-STD-P+ ...) ; compiling (DEFCONSTANT +SLOTD-WRITER-FUNCTION-STD-P+ ...) ; compiling (DEFCONSTANT +SLOTD-BOUNDP-FUNCTION-STD-P+ ...) ; compiling (DEFCONSTANT +SLOTD-ALL-FUNCTION-STD-P+ ...) ; compiling (DEFMETHOD SLOT-ACCESSOR-STD-P ...) ; compiling (DEFMETHOD (SETF SLOT-ACCESSOR-STD-P) ...) ; compiling (DEFMETHOD INITIALIZE-INTERNAL-SLOT-FUNCTIONS ...) ; compiling (DEFMETHOD COMPUTE-SLOT-ACCESSOR-INFO ...) ; compiling (DEFMETHOD SLOT-DEFINITION-ALLOCATION ...) ; compiling (DEFMETHOD CLASS-PROTOTYPE ...) ; compiling (DEF STD-CLASS) ; compiling (DEF CONDITION-CLASS) ; compiling (DEF STRUCTURE-CLASS) ; compiling (DEFMETHOD CLASS-DIRECT-DEFAULT-INITARGS ...) ; compiling (DEFMETHOD CLASS-DEFAULT-INITARGS ...) ; compiling (DEFMETHOD CLASS-SLOT-CELLS ...) ; compiling (DEFMETHOD (SETF CLASS-SLOT-CELLS) ...) ; compiling (DEFMETHOD ADD-DIRECT-SUBCLASS ...) ; compiling (DEFMETHOD REMOVE-DIRECT-SUBCLASS ...) ; compiling (DEFMETHOD ADD-DIRECT-METHOD ...) -> Aborting with an error -> unmounting dev/pts filesystem -> unmounting proc filesystem -> cleaning the build env -> removing directory /var/cache/pbuilder/build//10593 and its subdirectories Hmm, as you can see i'm using pdebuild so there shouldn't be any problems with the build environment. I _did_ make two changes to the source: i added an 'exit(0)' to the file 'tools-for-build/where-is-mcontext.c' (as was suggested on the mailing list) and a modified the 'find' pattern in clean.sh to avoid the problem with stage1 being deleted during the build (which still happens with the original build ... btw). Any ideas? Pointers? Cheers Ralf Mattes

On Wednesday 05 October 2005 10:21, R. Mattes wrote:
Hello Peter,
i just gave the newest sbcl source package a try - here's the outcome (stderror): ... ; caught 3 STYLE-WARNING conditions fatal error encountered in SBCL pid 24834: GC invariant lost, file "gc-common.c", line 190
Hey. I've been seeing this too, but as it was only on 'frost' I assumed it was flaky memory. I just retried it and it worked. Maybe 0.9.5.9 has some kind of problem?
Hmm, as you can see i'm using pdebuild so there shouldn't be any problems with the build environment. I _did_ make two changes to the source: i added an 'exit(0)' to the file 'tools-for-build/where-is-mcontext.c' (as was suggested on the mailing list) and a modified the 'find' pattern in clean.sh to avoid the problem with stage1 being deleted during the build (which still happens with the original build ... btw).
This should not happen anymore as the rules makefile saves the stage1 files in a tar file, which the find ignores, and then un-tars it again. How does it fail? Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|

On Thu, 2005-10-06 at 07:13 +0200, Peter Van Eynde wrote:
On Wednesday 05 October 2005 10:21, R. Mattes wrote:
Hello Peter,
i just gave the newest sbcl source package a try - here's the outcome (stderror): ... ; caught 3 STYLE-WARNING conditions fatal error encountered in SBCL pid 24834: GC invariant lost, file "gc-common.c", line 190
Hey. I've been seeing this too, but as it was only on 'frost' I assumed it was flaky memory. I just retried it and it worked. Maybe 0.9.5.9 has some kind of problem?
No idea. I don't think my box has memory problems - i often stress it to it's limits :-/
Hmm, as you can see i'm using pdebuild so there shouldn't be any problems with the build environment. I _did_ make two changes to the source: i added an 'exit(0)' to the file 'tools-for-build/where-is-mcontext.c' (as was suggested on the mailing list) and a modified the 'find' pattern in clean.sh to avoid the problem with stage1 being deleted during the build (which still happens with the original build ... btw).
This should not happen anymore as the rules makefile saves the stage1 files in a tar file, which the find ignores, and then un-tars it again. How does it fail?
To be fair, i never checked it with the latest build -- building takes such a long time and hogs resources i'm too frustrated by yet another deleted stage1. That's why i protect it in the clean.sh script. The only bug i'm concerned about is the memory problem. Cheers RalfD
Groetjes, Peter
participants (2)
-
Peter Van Eynde
-
R. Mattes