Error when interactive threads list is empty

Bug #1682671 reported by Syll on 2017-04-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Jan Moringen

Bug Description

In toplevel REPL, run this code and type 0 (continue) in the debugger (run in thread 2) before 10 seconds :
    ;; 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)
    ;; 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*

Jan Moringen (scymtym) on 2017-04-15
Changed in sbcl:
status: New → In Progress
assignee: nobody → Jan Moringen (scymtym)
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers