Steel Bank Common Lisp

DEFUN of a DEFMACRO from a locked package kills the original definition

Reported by Roman Marynchak on 2010-05-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Medium
Unassigned

Bug Description

SBCL 1.0.38, Linux 32 bit.

Enter this code in REPL:

* (defun defun(x) (error "Hi"))

you will see the next output

; in: LAMBDA NIL
; (SB-INT:NAMED-LAMBDA DEFUN
; (X)
; (BLOCK DEFUN (ERROR "Hi")))
; ==>
; #'(SB-INT:NAMED-LAMBDA DEFUN
; (X)
; (BLOCK DEFUN (ERROR "Hi")))
;
; caught STYLE-WARNING:
; DEFUN was previously defined as a macro.
;
; caught STYLE-WARNING:
; The variable X is defined but never used.
;
; compilation unit finished
; caught 2 STYLE-WARNING conditions
STYLE-WARNING: redefining DEFUN in DEFUN

debugger invoked on a SYMBOL-PACKAGE-LOCKED-ERROR in thread #<THREAD
                                                              "initial thread" RUNNING
                                                              {A9EB801}>:
  Lock on package COMMON-LISP violated when setting fdefinition of DEFUN.
See also:
  The SBCL Manual, Node "Package Locks"
  The ANSI Standard, Section 11.1.2.1.2

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE ] Ignore the package lock.
  1: [IGNORE-ALL ] Ignore all package locks in the context of this operation.
  2: [UNLOCK-PACKAGE] Unlock the package.
  3: [ABORT ] Exit debugger, returning to top level.

(PACKAGE-LOCK-VIOLATION #<PACKAGE "COMMON-LISP">)[:EXTERNAL]
0]

Now enter 3 - that is, we are not going to change DEFUN (right?).

After this, DEFUN becomes modified anyway. This code in REPL will signal the error now:

* (defun f(x) (+ x 1))

debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD
                                                   "initial thread" RUNNING
                                                   {A9EB801}>:
  The variable F is unbound.

Also, this is strange:

* (describe 'defun)

COMMON-LISP:DEFUN
  [symbol]

DEFUN names a compiled function:
  Lambda-list: (&REST ARGS)
  Derived type: (FUNCTION (T) NIL)
  Source file: SYS:SRC;COMPILER;INFO-FUNCTIONS.LISP

Why info-functions.lisp?

Note that the same problems are with COND and other macros. For the functions like EVENP, the package lock works fine, and they are not modified when performing the above steps.

Or I have missed something here?

Regards,
Roman

Nikodemus Siivola (nikodemus) wrote :

Gah, I'm pretty sure I've already fixes this once. Obviously the test-suite doesn't cover enough...

Changed in sbcl:
importance: Undecided → Medium
status: New → Triaged
summary: - Possible bug in the package lock functionality for DEFUN (and other
- macros)
+ DEFUN of a DEFMACRO from a locked package kills the original definition
Changed in sbcl:
assignee: nobody → Nikodemus Siivola (nikodemus)
status: Triaged → In Progress
Nikodemus Siivola (nikodemus) wrote :

Fixed in SBCL 1.0.42.28.

Re: why info-functions.lisp. Because (SETF MACRO-FUNCTION) also sets the corresponding SYMBOL-FUNCTION to a function that signals an error, so that (FUNCALL #'SOME-MACRO) will complain -- and that function happens to live in info-functions.lisp.

Changed in sbcl:
status: In Progress → Fix Committed
assignee: Nikodemus Siivola (nikodemus) → nobody
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers