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

Jaromir Matas mail at jaromir.net
Fri Oct 21 05:43:25 PDT 2022


Hi Gerald, Juan,

I have tried very quickly the same procedure in Squeak yesterday and my first impression was Squeak has some stuck terminated processes as well; I however haven't tried a clean image yet.

Another concern is Squeak 6 has implemented the same termination mechanism as Cuis (minus some most recent improvements regarding #isTerminated and the UI behavior). I very much hope it's not interfering with some low GC/VM stuff.

Please let me know what you find.

Btw I'm on Win 10.

Best,
Jaromir





From: Gerald Klix<mailto:cuis.01 at klix.ch>
Sent: Friday, October 21, 2022 13:37
To: Juan Vuletich<mailto:juan at cuis.st>
Cc: Jaromir Matas<mailto:mail at jaromir.net>; Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Subject: Re: [Cuis-dev] [DEFECT] Debugger leaves terminated processes

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20221021/b57bcc23/attachment-0001.htm>


More information about the Cuis-dev mailing list