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