(make-list nil) drops into LDB

[Jānis Džeriņš]

It appears that the argument check for MAKE-LIST triggers some kind of corruption, which causes heap exhaustion:

$ uname -a
Linux workbox 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ sbcl
This is SBCL 1.1.8.52-04d3bdf, 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.
* (lisp-implementation-type)

"SBCL"
* (lisp-implementation-version)

"1.1.8.52-04d3bdf"
* (machine-type)

"X86-64"
* *features*

(:QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ASDF-UNICODE
 :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :C-STACK-IS-CONTROL-STACK
 :COMMON-LISP :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF
 :FLOAT-EQL-VOPS :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS :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
 :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS
 :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE :SBCL
 :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)
* (make-list nil)

debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002AEB033}>:
  The value NIL is not of type (MOD 4611686018427387901).

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

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

Heap exhausted during garbage collection: 0 bytes available, 32 requested.
 Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age
   0: 0 0 0 0 0 0 0 0 0 0 0 10737418 0 0 0.0000
   1: 17784 0 0 0 9840 0 0 0 0 322332112 105008 10737418 0 0 1.0002
   2: 31850 31848 0 0 15215 28 0 0 11 499263200 219424 2000000 15205 0 0.0000
   3: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
   4: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
   5: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
   6: 0 0 0 0 1206 167 0 0 0 44990464 0 2000000 1130 0 0.0000
   Total bytes allocated = 1073384624
   Dynamic-space-size bytes = 1073741824
GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = in progress
   *STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 434(tid 140737353971520):
Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>

[Lutz Euler (lutz-euler)]

Bisected (on x86-64, Linux) to:

cd5a858174d892f876699373dc3ea389cf2c4d40 is the first bad commit
commit cd5a858174d892f876699373dc3ea389cf2c4d40
Author: Stas Boukarev <email address hidden>
Date: Wed Jun 5 18:38:42 2013 +0400

Optimize (mod FIXNUM) type-checks on x86oids.

Instead of two (and (>= x 0) (< x FIXNUM)) comparisons, do one
unsigned.
(mod power-of-two) is further optimized by doing one mask test
determine the range and fixnumness in one go.

[Paul Khuong (pvk)]

Well-coordinated C-c in a raw REPL shows

6: (SB-DEBUG::CLEAN-XEP (SB-C::TL-XEP MAKE-LIST) (4611686018427387900 NIL) (:EXTERNAL))

Old issue… We should either find a way to make sure the argument count is always in RCX, or cap (loop repeat count) to a low value (say a couple thousand arguments).

Paul Khuong

[Stas Boukarev (stassats)]

It's not actually caused by this commit directly, but is due to clobbering of RCX, the register where the number of arguments is passed. And the debugger uses it to reconstruct the arguments, 4611686018427387900 of them in this case. I can target the temporary register to RAX, but this problem is still present with any code inside XEPs which happens to touch RCX and throw an error.

[Christophe Rhodes (csr21-cantab)]

Paul Khuong <email address hidden> writes:

> Well-coordinated C-c in a raw REPL shows
>
> 6: (SB-DEBUG::CLEAN-XEP (SB-C::TL-XEP MAKE-LIST) (4611686018427387900
> NIL) (:EXTERNAL))
>
> Old issue… We should either find a way to make sure the argument count
> is always in RCX, or cap (loop repeat count) to a low value (say a
> couple thousand arguments).

Maybe it would be worth looking at setting a lowish value for
call-arguments-limit? I wonder what would actually break.

Christophe

[Stas Boukarev (stassats)]

What about just inserting something like (CONS 1 3 #<extraneous-args>) for any number of extra args, since the actual number of passed args will be shown in the error message anyway.

[Paul Khuong (pvk)]

Stas Boukarev wrote:
> What about just inserting something like (CONS 1 3 #<extraneous-args>)
> for any number of extra args, since the actual number of passed args
> will be shown in the error message anyway.
>

It's useful to know *what* the extra arguments are, when possible.

[Stas Boukarev (stassats)]

It is, but that doesn't happen currently.
(cons 1 2 3 4 5)
=>
(CONS 1 2 #<unknown> #<unknown> #<unknown>)

(CONS 1 2 #<extraneous-args>) instead of that wouldn't reduce clarity much, since the error is "invalid number of arguments: 5".

Making it into (CONS 1 2 3 4 5) is not easy, the debugger would need to know the calling conventions, which error the frame encountered and that none of the registers or stack locations are clobbered yet.

[Stas Boukarev (stassats)]

Fixed in 6e8818015788c80c3705748bebada273ff70370e.