Ticket #285 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

error calling call-next-method with safety 3

Reported by: gz Owned by: gb
Priority: major Milestone:
Component: ANSI CL Compliance Version:
Keywords: Cc:

Description

? (defclass c () ()) 
#<STANDARD-CLASS C> 
? (defmethod initialize-instance ((x c) &rest args) 
    (declare (optimize (safety 3)))
    (apply #'call-next-method x args)) 
#<STANDARD-METHOD INITIALIZE-INSTANCE (C)> 
? (make-instance 'c) 
> Error: value NIL is not of the expected type SIMPLE-VECTOR. 
> While executing: (:INTERNAL CCL::DO-IT CCL::%%CNM-WITH-ARGS-COMBINED-METHOD-DCODE), in process listener(1). 
> Type :POP to abort, :R for a list of available restarts. 
> Type :? for other options. 
1 >  

Change History

comment:1 Changed 6 years ago by gb

  • Owner changed from gz to gb
  • Status changed from new to assigned

comment:2 Changed 6 years ago by gb

We try to avoid consing up next-method-context info if we can tell that no applicable method needs it. Under more-heavily-exercised optimize settings, the compiler can reliably tell whether a method function does CALL-NEXT-METHOD; under SAFETY 3, it doesn't notice in some cases and the method function winds up claiming that it doesn't do CALL-NEXT-METHOD when in fact it does. Wackiness then ensues at runtime.

 (defmethod initialize-instance ((x c) &rest args) 
    (declare (optimize (safety 3)))
    (apply #'call-next-method x args)) 
#<STANDARD-METHOD INITIALIZE-INSTANCE (C)> 
? (lfun-bits * (logior (ash 1 $LFBITS-NEXTMETH-WITH-ARGS-BIT) (lfun-bits *)))
343965952
? (make-instance 'c)
#<C #x300040E46B9D>

So, clearly the user just has to set a bit in the method=function here ... or maybe the compiler should do this for them ?

comment:3 Changed 6 years ago by gb

  • Status changed from assigned to closed
  • Resolution set to fixed

This was apparently fixed in in changeset:9239.

Note: See TracTickets for help on using tickets.