[Cuis-dev] [DEFECT] Debugger leaves terminated processes

[Gerald Klix]

On 21.10.22 12:21, Juan Vuletich via Cuis-dev wrote:
> On 10/21/2022 6:48 AM, Gerald Klix via Cuis-dev wrote:
>>
>>> I just tried on a fresh Cuis.
>>> 1) Evaluated your killer 10M
>>> 2) waited for it to finish
>>> 3) closed the debugger.
>>> 4) 2 terminated processes.
>>> 5) Smalltalk garbageCollect
>>
>> Does this mean, we should explicitly trigger the GC,
>> after a Debugger window was closed/deleted/dismissed?
>>> 6) no terminated processes.
>>>
>>> Looks ok to me.
>> Hm?! See my question above.
>>
>>
>> Best Regards,
>>
>> Gerald
> 
> Runtimes that do garbage collection (not just Smalltalk, also Java, 
> JavaScript, DotNet, etc) will run GC when they detect some condition 
> that triggers it. At least in Smalltalk you can ask for GC when desired. 
> Not sure about the others.
I think the list of literature about garbage collection I read over
my professional life will certainly fill several pages. That's not the 
point.

I wrote “Hm”, because you did not follow the procedure,
that I suggested. If you omit `Smalltalk garbageCollect`
and do some other stuff, I rather sure, you will see the same
behavior. Unless, of course, the problems is related to Linux
or X11 and you used another OS for testing, presumably
MacOS.
> 
> The behavior of these systems is well documented elsewhere. There's 
> plenty of literature out there.
The behavior Jaromir and I observe -- disregarding any specification for
the opensmalltalkvm, I am not aware of such a thing -- indicates that
these processes tend to live for ever, unless we get rid of them early.
If you never save your image, this is of course less important.

Therefore, let me reformulate my question:

1. Is it a requirement for Cuis that image can be saved and
reused, even after a stopped non run-away recursion and other
severe failures?
2. Is calling the GC after closing a DebuggerWindow
a stop-gap-measure for avoid these lingering processes?
(Subject to further testing, of course. I am rather
pessimistic here: The ProcessBrowser repeatly
sends `garbageCollect` to `Smalltalk` and these
stuck processes won't go away, while the ProcessBrowser
is running)

I am aware that this needs further testing.
As a next step I will run that killer block on
a pristine Squeak 6.0 image using their VM.
If this does not show a difference, I will try to find out
which references keep those processes alive.
If Squeak handles this situation well,
I will start to to compare the debugger code.


Best Regards,

Gerald