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 <dionisiydk@gmail.com> wrote:
Hi.
It is probably related to issue 20309
2017-09-19 15:02 GMT+02:00 Holger Freyther <holger@freyther.de>:
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