Custom Query (1030 matches)

WITH-STANDARD-IO-SYNTAX is supposed to bind implementation-defined printer control variables to values that produce "standard" read/print behavior. There's at least some argument that binding CCL:*PRINT-ABBREVIATE-QUOTE* to T (as WITH-STANDARD-IO-SYNTAX currently does in CCL) is undesirable: the abbreviated syntax is certainly part of what CLHS calls "standard syntax", but if part of the purpose of WITH-STANDARD-IO-SYNTAX is to suppress implementation-dependent behavior, WITH-STANDARD-IO-SYNTAX should probably bind it to NIL instead.

Given:

$ cat warning.lisp
xyz    ;;; e.g., a reference to a non-special free variable

;;; EOF
$

we can get:

? (compile-file "foo.lisp" :save-source-locations nil)
> Error: value NIL is not of the expected type NUMBER.
> While executing: --2, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.

The error comes from code which tries to ensure that the COMPILER-WARNING will have an associated SOURCE-NOTE (presumably since if it didn't, the COMPILER-WARNING wouldn't have an associated SOURCE-NOTE ...) The SOURCE-NOTE's start-pos and end-pos are initialized to the value of *FCOMP-STREAM-POSITION*, which is NIL by the time this warning is signaled.

 (7FDCCEF42138) : 0 (--2 NIL NIL) 5245
 (7FDCCEF42170) : 1 (ENCODE-FILE-RANGE NIL NIL) 69
 (7FDCCEF42190) : 2 (MAKE-SOURCE-NOTE :FILENAME "home:warning.lisp.newest" :START-POS NIL :END-POS NIL :SOURCE NIL) 101
 (7FDCCEF421F8) : 3 (FCOMP-SIGNAL-OR-DEFER-WARNINGS (#<COMPILER-WARNING #x30200279B3ED>) #<LEXICAL-ENVIRONMENT #x30200279B67D>) 333
 (7FDCCEF42250) : 4 (FCOMP-NAMED-FUNCTION (LAMBDA NIL (PROGN XYZ)) NIL #<LEXICAL-ENVIRONMENT #x30200279CD9D> NIL) 597
 (7FDCCEF422C0) : 5 (FCOMP-COMPILE-TOPLEVEL-FORMS #<LEXICAL-ENVIRONMENT #x30200279CD9D>) 693

See ​http://clozure.com/pipermail/openmcl-devel/2012-May/013568.html

I was unable to reproduce this after doing:

? (progn
    (egc nil)
    (set-lisp-heap-gc-threshold (ash 512 20))
    (gc))

before calling (RUN), even when TEST/RUN created threads and RUN ran for 2500 iterations instead of 25. That suggests pretty strongly that this is a GC bug (or that the code involved in BIGNUM * FIXNUM multiplication doesn't follow register conventions correctly and that the failure occurs when such code is interrupted by GC in another thread.)

When a failure occurs, several words (in the "middle" of the result bignum) have incorrect values; the bignum is of the correct size and the words near both ends seem to be correct. This is also consistent with GC-related memory corruption.