Error in call to generic function while method being redefined

[Siebe de Vos]

Although CLOS/MOP and concurrency may not be fully supported, the PCL code is doing some attempts to prevent race conditions. The attached example shows that this is not enough: A generic function has two methods. When one of the methods is redefined, a concurrent call to the generic function from another thread may generate an error.

Note that the error is only transient. Calling the generic function after the method redefinition completes will yield the expected results. (But see https://bugs.launchpad.net/sbcl/+bug/1758921 for a persistently wrong result and a tentative patch. See https://bugs.launchpad.net/sbcl/+bug/1758878 for a heap exhaustion when the error reported here is repeatedly ignored.)

sbcl --load /home/vossi/wrk/method-transient-errors.lisp
This is SBCL 1.4.5, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.

#<TYPE-ERROR expected-type: (INTEGER 1 4611686018427387902) datum: 0>
*

uname -a
Linux si2l 4.4.92-31-default #1 SMP Sun Oct 22 06:56:24 UTC 2017 (1d80e8a) x86_64 x86_64 x86_64 GNU/Linux

*features* =>
(:64-BIT :64-BIT-REGISTERS :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
 :C-STACK-IS-CONTROL-STACK :CALL-SYMBOL :COMMON-LISP :COMPACT-INSTANCE-HEADER
 :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS
 :FP-AND-PC-STANDARD-SAVE :GCC-TLS :GENCGC :IEEE-FLOATING-POINT :IMMOBILE-CODE
 :IMMOBILE-SPACE :INLINE-CONSTANTS :INTEGER-EQL-VOP :LARGEFILE :LINKAGE-TABLE
 :LINUX :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
 :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC
 :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :RAW-INSTANCE-INIT-VOPS
 :RAW-SIGNED-WORD :RELOCATABLE-HEAP :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB
 :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-THREAD :SB-UNICODE
 :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UNBIND-N-VOP
 :UNDEFINED-FUN-RESTARTS :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)

[Siebe de Vos (s.de.vos)]

Are you sure this is a duplicate of https://bugs.launchpad.net/bugs/1153309? That one seems to have a problem with typep after a single class definition. The bug described here is in PCL:

(%MAKE-CACHE :KEY-COUNT 0 ...) violates the structure definition of cache, with

0: (SB-PCL::MAKE-CACHE :KEY-COUNT 0 :VALUE T :SIZE 2)
1: (SB-PCL::MAKE-CONSTANT-VALUE-DFUN #<STANDARD-GENERIC-FUNCTION COMMON-LISP-USER::F (2)> NIL)
2: (SB-PCL::CHECKING-MISS #<STANDARD-GENERIC-FUNCTION COMMON-LISP-USER::F (2)> (NIL) #<SB-PCL::CHECKING {1001DC84F3}>)
3: ((LAMBDA NIL :IN TEST-METHOD))

when you run :

(defun test-method (&key (callers 1))
  (let ((i (make-instance 'c))
        (error nil))
    (dotimes (i callers)
      (sb-thread:make-thread
       (lambda ()
         (loop
           (handler-bind ((error
                           (lambda (error*)
                             (print-backtrace)
                             (setf error error*))))
             (f nil))
           (when error (return)))
         :name (format nil "Caller"))))
    (loop
      (defmethod f ((x c)) x)
      (when error (return)))
    (assert (and (eq (f nil) t)
                 (eq (f i) i)))
    (print error)))