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

[Gerald Klix]

On 21.10.22 13:37, Gerald Klix via Cuis-dev wrote:
> 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

I tried the 10M killer block with Squeak 6.0,
with the following result

1st) Count the terminated processes: 0
2nd) Run the killer block.
3rd) While in the PreDebugger, count terminated processes: 0
4th) Open the debugger, count: 0
5th) Close the debugger, count: 0

When I do but save and quit the image, before closing
the PreDebugger I get the 1.9 GB image (no surprise).
When close the PreDebugger, save and quit, I am up 140MN from 54MB.
When run `Smalltalk garbageCollect`, save and quit, I am down to 50M 
image size.

Doing the same with Cuis and Squeak's VM, the image size stays at 1.9GB.

I don't like this behavior.


Sorry,

Gerald