2016-01-20 23:23 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:

2016-01-20 19:18 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:

2016-01-20 14:47 GMT+01:00 Andrei Chis <chisvasileandrei@gmail.com>:
Tried it in the last latest image and if I execute before #garbageCollect I just get 4 instances.

Smalltalk garbageCollect.
RubTextLine allInstances size "4"

Now indeed if I browse the same class in nautilus I get a much smaller number of��RubTextLine instances

I opened a bugreport

17437��
Rubric: spotter with preview leaks some memory

I tried to reproduce this behavior with GTInspector instead of Spotter, for example, inspect:

MethodFinder methods
select on entry, -> another inspector pane shows up. Select th "Source"-tab. Now
scroll through the list of methods in the first inspector pane. For every method the second pane updates the
source tab with the code of the selected method.

This generates many RubTextLine instances too. But not as many and I can always clean them up with Smalltalk garbageCollect.
So, the is something that spotter does differently.

And even if Smalltalk garbageCollect would clean all instances,
I don't think it is right, that scrolling through the method list (with preview) should create hundred thousends of RubTextLine instances.

There is just not enough code visible, we definitly don't need that much. There is something wrong.

��

��

��

On Wed, Jan 20, 2016 at 2:32 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
Open fresh image 50536
Open Spotter,
enable preview (cmd+p)
search for EllipseMorph
dive in instance-methods
scroll through the list one item after another.

open playground
evaluate
RubTextLine allInstances size. "553896"

case 17421 is related to this, but does not fully solves this.
please review and comment on that fix,
so we can integrate this soon.

The problem sometimes remains even with this fix. The memory
(instance count of RubTextLine) just grows in the background