On Sun, 2 Feb 2014, Chris Muller wrote:

> Hi Levente, the new structure of LRUCache seems to expose a problem
> with chasing pointers.  When I try to chase pointers to any object,
> one of the LRUCache's
>
> I'm still digging to try and see whether its a bug with chasing
> pointers or just a stack-depth limitation.  What I see so far is that
> PointerFinder wants to ask whether the 'head' var of the new LRUCache
> #isLiteral.  That is what leads to the VM crash.
>
>    (LRUCache allInstances anyOne instVarNamed: 'head') isLiteral
>
> I noticed the 'head' var is initialized as a two-element Array, with
> each element being the array itself.  So trying to ask an Array
> #isLiteral won't work in that case, e.g.,
>
>     |a| a:=Array new: 1.
>     a at: 1 put: a.
>     a isLiteral
>
> causes the same issue.
>
> Clearly, we cannot release with a broke PointerFinder.  So, what's the
> best fix folks?  My first reaction is a guard in Array>>#isLiteral?

So the cause of the problem is PointerFinder >> #follow:from:. I see two 
problems there:
1. it sends #isLiteral to improve performance, but it can't really save 
much
2. it rejects all objects having a weak class (via 
#shouldFollowOutboundPointers), but those objects can have instance 
variables (e.g. WeakFinalizerItem), which are strong references.

See Tools-ul.518 in the Inbox with my proposed fix.


Levente

P.S.: There was a comment in the earliest version in my image:

"Remove this after switching to new CompiledMethod format --bf 2/12/2006"

It's not clear what _this_ means, but your latest version (cmm 5/26/2013) 
lacks the comment, but no logic was removed.

>
>     isLiteral
>          ^ self class == Array and: [ (self includes: self) not and:
> [ self allSatisfy: [ : each | each isLiteral ] ] ]
>
> Thanks.
>