Hi Stef,
I think it is because forContext:priority: does not schedule the process, just creates it. The debugger code steps the process but after stepping the process is still not runnable. So the process terminate is unnecessary; the process should not have been added to the run queue and should juts be GCed. Since it is not the question is what refers to the process after the test has run.
To debug, I would rewrite the test as such:
testBasic
| process debugger printedString |
process := Process
forContext: [ 20 factorial ] asContext
priority: Processor activePriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
^process
and then chase pointers on the result to see what is holding onto the process. Sicne the process is never runnable there's no need to set its priority to anything special.
However, one should also be able to replace the "process terminate" with "process resume" to get it to run to termination (provided its priority stays at Processor userInterruptPriority).
HTH