Debugger-induced corruption

[Douglas Katzman]

A function with one &optional arg is printed with an innocuous (but wrong) value for the missing arg based on whatever was on stack:
* (getf 'x '(a b c d))

debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1001278083}>:
  The value X is not of type LIST when binding SB-IMPL::PLACE

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.

(GETF X (A B C D) 34363007224) [external]

However, things go to hell if the unsupplied value location holds a wild pointer:

* (getf 'x '(a b c d))
debugger invoked on a TYPE-ERROR in thread
... ["X is not of type LIST" prints fine, but ...]

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.

CORRUPTION WARNING in SBCL pid 196276(tid 0x7f9fe657cb80):
Memory fault at 0xfee8e898 (pc=0x52a7e6e1 [code 0x52a7e550+0x191 ID 0x71c2], fp=0x7f9fe62e6810, sp=0x7f9fe62e6800) tid 0x7f9fe657cb80
The integrity of this image is possibly compromised.
Continuing with fingers crossed.

debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD "main thread" RUNNING {1000618083}>: Unhandled memory fault at #xFEE8E898.

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.

CORRUPTION WARNING in SBCL pid 196276(tid 0x7f9fe657cb80):
Memory fault at 0xfee8e898 (pc=0x52a7e6e1 [code 0x52a7e550+0x191 ID 0x71c2], fp=0x7f9fe62e5618, sp=0x7f9fe62e5608) tid 0x7f9fe657cb80
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
CORRUPTION WARNING in SBCL pid 196276(tid 0x7f9fe657cb80):
Memory fault at 0xfee8e8a0 (pc=0x5202a3ed [code 0x5202a0d0+0x31D ID 0xb0a], fp=0x7f9fe62e5690, sp=0x7f9fe62e5688) tid 0x7f9fe657cb80
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
((LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1.) :IN "SYS:SRC;PCL;DLISP3.LISP") #<error printing object> #<SB-PRETTY:PRETTY-STREAM {10015EE9C3}>)

The backtrace at that point is:
Backtrace:
   0: (LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1.) :IN "SYS:SRC;PCL;DLISP3.LISP"), pc = 0x52a6f351, fp = 0x7f74b6fc6b18
   1: (LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL::OUTPUT-OBJECT), pc = 0x52022206, fp = 0x7f74b6fc6b80
   2: SB-INT::%WRITE, pc = 0x52046188, fp = 0x7f74b6fc6ba0
   3: SB-DEBUG::PRINT-FRAME-CALL, pc = 0x520b3f90, fp = 0x7f74b6fc6d10
   4: SB-DEBUG::DEBUG-LOOP-FUN, pc = 0x5249e6d9, fp = 0x7f74b6fc6de0
   5: SB-DEBUG::INTERNAL-DEBUG, pc = 0x5249e06b, fp = 0x7f74b6fc6df0
   6: (FLET DEBUG :IN SB-DEBUG::%INVOKE-DEBUGGER), pc = 0x522abd51, fp = 0x7f74b6fc6e88
   7: SB-DEBUG::%INVOKE-DEBUGGER, pc = 0x522ab770, fp = 0x7f74b6fc6f20

If execution is stopped at the first entrance into PRINT-FRAME-CALL before things have gotten worse, 'gdb' will show (in this example) that the wild pointer has fun-pointer-lowtag pointing to a word that ostensibly has SAP-WIDETAG but in fact is just instruction bytes.

Program received signal SIGSEGV, Segmentation fault.
0x0000000052a6f351 in ?? ()
(gdb) call print(0x10015e6f87) ; this the ARGS list obtained from FRAME-CALL
$1= 0x10015e6f87: list pointer
$2= car: 0x10015d738f: X
$3= cdr: 0x10015e6f97: ($4=($5=A $6=B $7=C $8=D) $9=#<ptr to sap>)
(gdb) x/2xg 0x10015e6f90
0x10015e6f90: 0x00000010015d7457 0x00000010015e6fa7
(gdb) x/2xg 0x00000010015e6fa0 ; show the CDR of ^
0x10015e6fa0: 0x0000000052059cab 0x0000000050100017 ; low byte of 'b' is fun-pointer
(gdb) x/2xg 0x0000000052059ca0
0x52059ca0: 0xfee8e88b4910894d 0x48e3420f48fffff7

I think we might be able to mitigate some of the problem by checking more carefully what FRAME-CALL returns. I don't any blame can be placed on %WRITE etc for not understanding how to print junk.