Error when interactive threads list is empty

[Syll]

In toplevel REPL, run this code and type 0 (continue) in the debugger (run in thread 2) before 10 seconds :
  (progn
    ;; Create a new thread
    (sb-thread:make-thread (lambda () (break)) :name "Thread 2")
    ;; Wait for the debugger to be called
    (sleep 1)
    ;; Main thread releases foreground (and Thread 2 gets it, displaying debugger)
    (sb-thread:release-foreground)
    ;; Type 0 (continue) to end Thread 2 while main thread is waiting
    (sleep 10))

SBCL should return to REPL in main thread, then main thread sould call get-foreground et get foreground.

What happens : infinite loop displaying errors.

With Ctrl + S or recreating the error with Thread 2 by calling sb-thread::get-foreground instead of break and running sbcl with --disable-debugger, it seems that the original error is "NIL is not of type CONS" in get-foreground or a function called from get-foreground (I don't understand the top of the backtrace).

Displaying (sb-thread::session-interactive-threads sb-thread::*session*) is useful to get the list of interactive threads at a given time.

Pushing main-thread in (sb-thread::session-interactive-threads sb-thread::*session*) before it goes back to REPL and calls get-foreground prevents the error. Add after (sleep 10) : (push (sb-thread:main-thread) (sb-thread::session-interactive-threads sb-thread::*session*))

I don't understand from the backtrace where the error happens exactly but it seems that get-foreground don't like the list of interactive threads being empty.

what seems happening : the second thread gets foreground, main-thread releases foreground (release-foreground checks if there is something else in the list of interacive threads and yes : Thread 2 is in the list), then Thread 2 ends and there is nothing remaining in the list (the thread is probably removed from the list without being replaced by another one). Calling get-foreground at this time signals a type error somewhere (which is the main problem). Then debugger is called and calls get-foreground too, which signals a second error because of a non-recursive lock in get-foreground (this second problem is not the important one, but it generates an infinite error loop).

(is get-foreground intented to be used by user ? it is noted in SBCL manuel with release-foreground and seems useful but it is an internal symbol)

------------

$ sbcl --version
SBCL 1.3.15

$ uname -a
Linux yggdrasil 4.10.9-1-ARCH #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST 2017 x86_64 GNU/Linux

* *features*
(:64-BIT :64-BIT-REGISTERS :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
 :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPACT-INSTANCE-HEADER
 :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS
 :FP-AND-PC-STANDARD-SAVE :GENCGC :IEEE-FLOATING-POINT :IMMOBILE-CODE
 :IMMOBILE-SPACE :INLINE-CONSTANTS :INTEGER-EQL-VOP :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 :PRECISE-ARG-COUNT-ERROR
 :RAW-INSTANCE-INIT-VOPS :RAW-SIGNED-WORD :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL
 :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS
 :SB-THREAD :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES
 :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS
 :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS
 :UNBIND-N-VOP :UNDEFINED-FUN-RESTARTS :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP
 :X86-64)