Ups, wrong thread…

On 16 Nov 2015, at 11:47, Marcus Denker <marcus.denker@inria.fr> wrote:

I can not reproduce it with a recent vm…

...

On 16 Nov 2015, at 11:44, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Andrei,

you should be able to use whatever the equivalent of the PointerFinder is these days to find out. Once you have your instances from all instances you can find the path from the roots that is keeping them alive via PoinerFinder openOn: anInstance IIRC.

_,,,^..^,,,_ (phone)

...

On Nov 16, 2015, at 6:22 AM, Andrei Chis <chisvasileandrei@gmail.com> wrote:

Hi,

In the latest Pharo image there is a rogue instance of GLMSystemWindow. If I do in the console the following code I get one instance:

/pharo Pharo.image eval "GLMSystemWindow allInstances" an Array(a GLMSystemWindow(58720256))

There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window.

./pharo Pharo.image eval "SystemWindow allSubInstances" an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256))

If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays:

./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances" an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712))

Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it?

Cheers, Andrei

We checked again and with the Spur VM all the strange memory leaks that we had with the GLMSystemWindow/Inspector/Playground seem to have disappeared (for now :) ) Cheers, Andrei On Mon, Nov 16, 2015 at 3:52 PM, Henrik Nergaard <henrin10@student.uia.no> wrote:

The RubFindReplaceDialogWindow is made and held by RubFindReplaceService ivar dialog. There is also the ivar textAreaHolder which holds the active text area. When setting this variable from #textArea: an announcement is created for the textArea to the RubFindReplaceService, this should probably be a weak one.

I think the main issue is that the textArea instance variable is not cleared from RubFindReplaceService when it is deleted.

There is also announcements linked to RubFindReplaceService made by: RubAbstractTextArea>>#plugFindReplace. I guess these announcements should be weak.

Hope this helps,

Best regards,

Henrik

*From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf Of *Andrei Chis *Sent:* Monday, November 16, 2015 3:23 PM *To:* Discusses Development of Pharo <pharo-dev@lists.pharo.org> *Subject:* [Pharo-dev] last opened window does not go away

Hi,

In the latest Pharo image there is a rogue instance of GLMSystemWindow.

If I do in the console the following code I get one instance:

/pharo Pharo.image eval "GLMSystemWindow allInstances"

an Array(a GLMSystemWindow(58720256))

There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window.

./pharo Pharo.image eval "SystemWindow allSubInstances"

an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256))

If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays:

./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances"

an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712))

Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it?

Cheers,

Andrei