Custom Query (1030 matches)

Once in a while, dumping an image using CCL yields a dysfunctional executable that crashes with low-level errors when used.

My guess, coherent with the symptoms, is that there is a race condition that causes threads to not be cleaned up properly before the image is dumped, and the runtime is subsequently confused when it resumes from such an messed up state. If correct, then a solution would then better to synchronize with threads being terminated, and/or to teach the runtime to clean up the mess when re-starting.

I've observed the symptom in the past, using CCL 1.7 while compiling QRes and probably earlier versions of CCL. But there was too much state to be reproducible, what more involving proprietary software. Today, I reproduced the bug with CCL 1.8, during the early steps of an XCVB build, therefore with very little state if at all, while testing XCVB itself, all of it free software. Attached will be the log of all XCVB testing (27MB uncompressed, .5MB bzip2'ed) - search for TYPE-ERROR near the end, and the resulting dysfunctional image (27MB uncompressed, 5MB bzip2'ed).

Ubuntu Lucid on amd64
linux-image-2.6.32-41-generic
libc6-2.11.1-0ubuntu7.10
Clozure Common Lisp Version 1.8-r15359M  (LinuxX8664)
XCVB 0.579-5-gb4086ee

The (reformatted) commands run to build the dysfunctional image were:

ccl --no-init --quiet --batch --eval \
  "(let ((x
          (multiple-value-bind (output warningp failurep)
              (let ((*default-pathname-defaults*
                     (truename *default-pathname-defaults*)))
                (handler-bind (((or #+sbcl sb-c::simple-compiler-note
	                              #+ecl c::compiler-note
			              #+ecl c::compiler-debug-note
			              #+ecl c::compiler-warning)
				  #'muffle-warning))
                  (compile-file \"/tmp/tunes/xcvb-release/xcvb/driver.lisp\"
                    :verbose nil :print nil :output-file
		      (merge-pathnames
		       #P\"/tmp/tunes/xcvb-test/obj/xcvb/driver__temp.lx64fsl\"))))
	      (if (or (not output) #-(or clisp ecl) warningp #-clisp failurep)
	        1 0))))
     (finish-output *standard-output*) (finish-output *error-output*)
     (ccl:quit x))"

mv /tmp/tunes/xcvb-test/obj/xcvb/driver__temp.lx64fsl \
  /tmp/tunes/xcvb-test/obj/xcvb/driver.lx64fsl

xcvb make-manifest --output \
  /tmp/tunes/xcvb-test/obj//___initial.manifest --spec \
  "((:command (:load-file (:fasl \"/xcvb/driver\"))
     :pathname \"/tmp/tunes/xcvb-test/obj//xcvb/driver.lx64fsl\"))"

ccl --no-init --quiet --batch --load \
  /tmp/tunes/xcvb-test/obj//xcvb/driver.lx64fsl --eval \
  "(xcvb-driver::run
     (:create-image (#P\"/tmp/tunes/xcvb-test/obj/___temp.image\"
                    :output-name \"_\" )
       (:initialize-manifest
         \"/tmp/tunes/xcvb-test/obj//___initial.manifest\")))"

mv /tmp/tunes/xcvb-test/obj/___temp.image \
  /tmp/tunes/xcvb-test/obj/_.image

The next command, that triggered the error, was:

/tmp/tunes/xcvb-test/obj/_.image --no-init --quiet --batch --eval \
  "(xcvb-driver::run
     (:compile-lisp
       (\"/tmp/tunes/xcvb-release/xcvb/examples/example-1/package.lisp\"
        #P\"/tmp/tunes/xcvb-test/obj/xcvb/example-1/package__temp.lx64fsl\")))"

The (reformatted) error output before the process exited with error code 255 was:

> Error of type TYPE-ERROR: value 0 is not of the expected type
(OR CCL::NAMED-CTYPE CCL::NUMERIC-CTYPE CCL::ARRAY-CTYPE CCL::MEMBER-CTYPE
    CCL::CLASS-CTYPE CCL::UNION-CTYPE CCL::INTERSECTION-CTYPE CCL::CONS-CTYPE
    CCL::UNKNOWN-CTYPE CCL::NEGATION-CTYPE CCL::HAIRY-CTYPE CCL::FUNCTION-CTYPE).
> While executing: CCL::%%TYPEP, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).

Note that:

• while I have single-threaded-ccl installed (git revision 608cd4), it wasn't used at that time. Which is consistent with the error being a threading race condition.
• while this is kernel 2.6.32, it doesn't have CONFIG_PREEMPT enabled, only CONFIG_PREEMPT_VOLUNTARY, so it is likely not the same kernel bug as was causing ITA bug 87457.
• the machine was lightly loaded with web browsing at the time I was running the test. I suspect that increasing CPU load might increase the chances at reproducing the bug.
• loading the driver fasl is a very very thin wrapper over directly calling ccl:save-application. You might be able to reproduce the bug just by calling plenty of save-applications in parallel.
• I didn't spend as much time writing this bug report the second time (see bug 979), and this time, I'm saving it to a file before to submit it.

Xref: ITA bug 106299

I'm under Clozure Common Lisp Version 1.1-r9799S (DarwinX8632).

Compile IRONCLAD, the pure lisp encrpyt package, failed. See attach for backtrace.

On moving a Lisp application to a newer Linux box, we get random, whacky behaviour. This is demonstrated by the following file:

=== process-test.lisp ===
(in-package :cl-user)

(defun big-sum (n)
  (let ((total n))
    (dotimes (i n total)
      (incf total i))))

(defun test ()
  (ccl:process-run-function "25" #'big-sum 250000000)
  (ccl:process-run-function "26" #'big-sum 260000000)
  (ccl:process-run-function "27" #'big-sum 270000000)
  (ccl:process-run-function "28" #'big-sum 280000000))

and session transcript:

$ uname -a
Linux startle 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
$ ccl
Welcome to Clozure Common Lisp Version 1.6  (LinuxX8632)!
? (load "process-test.lisp")
#P"/home/startle/startle/process-test.lisp"
? (test)
#<PROCESS 28(5) [Reset] #x1828FA76>
? 
> Error: Fault during read of memory address #x634
> While executing: CCL::*-2, in process 26(3).


;;;
;;; #<PROCESS 26(3) [Active] #x182901B6> requires access to Shared Terminal Input
;;; Type (:y 3) to yield control to this thread.
;;;
> Error: value #<BOGUS object @ #x284E4729> is not of the expected type NUMBER.
> While executing: CCL::+-2, in process 27(4).


;;;
;;; #<PROCESS 27(4) [Active] #x1828FE16> requires access to Shared Terminal Input
;;; Type (:y 4) to yield control to this thread.
;;;
> Error: value #<Unprintable CCL::IMMEDIATE : #x34D0C3> is not of the expected type NUMBER.
> While executing: CCL::*-2, in process 28(5).


;;;
;;; #<PROCESS 28(5) [Active] #x1828FA76> requires access to Shared Terminal Input
;;; Type (:y 5) to yield control to this thread.
;;;

The exact error messages are variable. Above transcript from x86 Ubuntu 10.04 box; similar behaviour from x86 Centos 5.6. However, x86 Centos 5.3 (and earlier) does not show this, nor does Darwin/PPC (CCL 1.4).