[armedbear-devel] The value :LONG is not of type (MEMBER NIL :BOOLEAN)

Chun Tian (binghe) binghe.lisp at gmail.com
Mon Mar 21 11:37:20 UTC 2011

Hi, Alesio

Oh, sorry, maybe I didn't say it clearly, the "Register 4 contains wrong type" is not produced by the file with THREADS:WITH-MUTEX. It's another issue, not relevant to the first post in this mail thread.

Following function caused the "Register 4 contains wrong type" issue:

(defun generate-table (vars vbs non-repeaters max-repetitions)
  (declare (type fixnum non-repeaters max-repetitions))
  (let* ((var-number (list-length vars))
         (n (min non-repeaters var-number))
         (m max-repetitions)
         (r (max (- var-number n) 0))
         (real-vbs (mapcar #'(lambda (x) (coerce x 'list))
                           (coerce vbs 'list)))
    ;; non-repeaters
    (dotimes (i n)
      (push (pop real-vbs) result-table))
    ;; table
    (when (and (plusp m) (plusp r))
      (dotimes (i m)
        (push (let (record)
                (dotimes (j r (nreverse record))
                  (push (pop real-vbs) record)))
    (values (nreverse result-table)
            (mapcar #'oid vars))))

If I temporary disable it by #+ignore or #-abcl, than the whole project compiles with no error any more. I'll try to continue look for which exactly form in this function caused the error.


Chun Tian (binghe)

在 2011-3-21,19:21, Alessio Stalla 写道:

> 2011/3/21 Chun Tian (binghe) <binghe.lisp at gmail.com>:
>> Hi, Alessio
>> Thank you for pointing out this. You're right.  IF I temporary removed the LOGAND form and just return the inner ATOMIC-INCF form, then everything goes well, compilation can pass.
>> The next issue happens in a file which has some method definitions, ABCL report "Register 4 contains wrong type" when loading a just compiled .abcl file:
>> ; Loading #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp-get.abcl" ...
>> Do you have any idea about this? i.e. What's "Register 4"?
> It's a JVM register, used to hold some intermediate result. The
> compiler is producing incorrect code: probably it doesn't derive the
> right type for the atomic-incf form. I see that
> expands to
>      (THREADS:RELEASE-MUTEX #:G3433))))
> Maybe there's a problem with the derived type of unwind-protect forms,
> but I don't have the source at hand now to check.
> Alessio

More information about the armedbear-devel mailing list