<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> Hi Juan, Gerald,<o:p></o:p> <o:p> </o:p> this is weird; some terminated processes get stuck in the system because they are being referenced which is why they don't get garbage collected (stating the obvious, I know); the question that puzzles me is why they are being referenced... which is unfortunately beyond my 'paygrade' (i.e. my skills) ;)<o:p></o:p> <o:p> </o:p> you can see an example of such a "stuck" process here:<o:p></o:p> <o:p> </o:p> Smalltalk garbageCollect.<o:p></o:p> process _ ( Process allSubInstances select: [ :process | process isTerminated ] ) anyOne.<o:p></o:p> ( Object allSubInstances select: [:obj | obj pointsTo: process] ) explore<o:p></o:p> <o:p> </o:p> In most cases the newly terminated processes get garbage collected shortly (automatically) but some get stuck somehow (because referenced) and seem to stay stuck. I'm observing a similar behavior in older images from earlier this year so the most recent modification in isTerminated or the UI behavior should not be causing it.<o:p></o:p> <o:p> </o:p> I'm not sure these 'stuck' terminated processes can cause memory issues Gerald observes but the truth is I don't understand the mechanism why they keep being referenced (and hence stuck).<o:p></o:p> <o:p> </o:p> I hope someone could shed some light here or point in the right direction. I'd like to make sure the changes in termination I suggested are not causing somehow this behavior, and fix them if they do, of course.<o:p></o:p> <o:p> </o:p> best,<o:p></o:p> Jaromir<o:p></o:p> <o:p> </o:p> --<o:p></o:p> Jaromír Matas<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: <a href="mailto:cuis.01@klix.ch">Gerald Klix</a> Sent: Thursday, October 20, 2022 18:20 To: <a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>; <a href="mailto:juan@cuis.st"> Juan Vuletich</a> Cc: <a href="mailto:mail@jaromir.net">Jaromir Matas</a> Subject: [DEFECT] Debugger leaves terminated processes </div> <o:p> </o:p> Hi all, Hi Juan, I think I found the cause of my huge images: The Debugger (or process termination) leaves terminated processes hanging around. First I saved the image before running the killer-Block (see the attached killit.st): -- snip -- beforeLargeStack.image -rw-rw-r-- 1 bear bear 27M Okt 20 17:50 Haver6.0-5496-beforeLargeStack.image -- snap -- Than I ran killit and simply closed the debugger window and saved the image: -- snip -- -rw-rw-r-- 1 bear bear 1.9G Okt 20 17:51 Haver6.0-5496-afterLargeStack.image -- snap -- From 27 megabytes to 1.9 gigabytes in 20 seconds, that's quite a feature, albeit a bad one. When I print all existing processes -- see diagnoseKillit.st -- I could see there are a lot of terminated processes hanging around. I did `self break` and closed the debugger: More terminated processes. Bad enough: `Smalltalk garbageCollect` does not help. The first part of RunningProcesses.txt is the transcript output after running the killer-block. (There are already some terminated processes, because I used image to implement the fixes, I just posted). The second part is transcript output after one `self break`; I didn't check exactly, but there are more terminated processes. Best Regards, Gerald<o:p></o:p> <o:p> </o:p> </div> </body> </html>