failed AVER: (NULL CURRENT)

Bug #1305300 reported by Nikita Sadkov on 2014-04-09
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Undecided
Unassigned

Bug Description

I reproduced the bug on SBCL 1.0.58 and 1.1.17. It is somehow related to NREVERSE macros arguments, because REVERSE doesn't trigger SB-INT:BUG.

$ uname -a
Darwin snv-mbp.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

$ sh run-sbcl.sh
(running SBCL from: .)
This is SBCL 1.1.17, 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.
* (defmacro foo (xs)
  (second (reduce
           (lambda (n x)
             (cons (cons t (cons '(= t t) x))
                   n))
           (cons () (nreverse xs)))))

FOO
* (defun bar () (foo (t ((t)))))

debugger invoked on a SB-INT:BUG:
    failed AVER: (NULL CURRENT)
  This is probably a bug in SBCL itself. (Alternatively, SBCL might have been
  corrupted by bad user code, e.g. by an undefined Lisp operation like
  (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe
  Lisp code; or there might be a bug in the OS or hardware that SBCL is running
  on.) If it seems to be a bug in SBCL itself, the maintainers would like to
  know about it. Bug reports are welcome on the SBCL mailing lists, which you
  can find at <http://sbcl.sourceforge.net/>.
restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-INT:BUG "~@<failed AVER: ~2I~_~A~:>" (NULL SB-C::CURRENT))
0]

Paul Khuong (pvk) wrote :

Your macro is mutating source, via nreverse. This is a bad idea in many ways. I'm not even sure that I want to remove that AVER: it reflects the fact that the mutated source makes no sense anymore.

Nikita Sadkov (snv985) wrote :

We have a few solutions:
1. make a copy of SEXP for each macro application (inefficient but robust)
2. give a warn for any nreverse/nconc/rplaca/rplacd inside of a macro (efficient, but non-robust)
3. forbid rplaca/rplacd on compiler allocated structures (efficient and robust)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers