There was a long post from Guille about how to sort this. It had to do with altering the priority of shutdown code - I'm not sure if we resolved it, but we should go back and see as it was well reasoned.
Tim Sent from my iPhone > On 19 Sep 2017, at 14:20, Denis Kudriashov <[email protected]> wrote: > > Hi. > > It is probably related to issue 20309 > > 2017-09-19 15:02 GMT+02:00 Holger Freyther <[email protected]>: >> Hi, >> >> I am currently trying to run one of my images as non-root and related to >> that look into keeping changes in a different directory or not writing them >> at all. While looking at a write failure I saw some paths being logged that >> I used during CI to load code and should have been GCed. >> >> >> Observation: >> >> >> Pharo --headless My.image eval "Smalltalk garbageCollect. CommandLineHandler >> allSubInstances size" >> 84 >> >> Pharo --headfull My.image eval "Smalltalk garbageCollect. CommandLineHandler >> allSubInstances size" >> 2 >> >> >> As part of the CommandLineHandler allSubInstances there are eight >> LoadUpdatesCommandLineHandler still active. I would assume that a full GC >> should have collected them by now (some of them being created in May). In a >> headfull image they disappear quickly >> >> I varied the execution a bit: >> >> Pharo --headless RoamingHub.image eval --no-quit "[ Smalltalk >> garbageCollect. FileStream stdout print: CommandLineHandler allSubInstances >> size; lf. Smalltalk snapshot: false andQuit: true] fork" >> 0 >> >> >> Hypothesis: >> >> >> * Command line handlers call >>#snapshot:andQuit:. >> * Image resumes in this process >> * New session created >> * Command line handlers execute >> * Calls snapshot:andQuit: >> * Image resumes.. >> * New session created >> * Command line handlers execute >> ... >> >> >> Can this be true? I think the proposal to start the image differently would >> help here? Any comments/ideas? >> >> holger >
