Steven Schveighoffer <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #2 from Steven Schveighoffer <> 2010-03-11 
03:43:16 PST ---
Hm... first off, the LRU cache is only used for appending.  So in order for the
LRU cache to mistakenly access unallocated memory, you must be appending to an
invalid array.

Second, the LRU cache stores blockinfos, which should never change except in
one case.  That one case is when an array greater than half a page size is
appended to, it can grow in place by appending more pages to the blockinfo. 
This means a stale blockinfo could identify a memory block as being larger or
smaller than it actually is.  I would expect AA nodes to be small enough to not
trigger this problem.

If you clear the cache on a GC run, then you remove the cache's usefulness
since a GC run occurs only when new memory is requested.  If you clear it on GC
free, you have to stop all threads.  I don't think either of these solutions
will work, but I also don't think the LRU cache is causing problems.

Can we try to disable the cache to rule it out?  I suspect there is another
issue with AA's related to the appending fix, but I think it has to do with the
fact that AAs are allocating arrays without using the runtime functions for
arrays (it calls GC.malloc directly and builds the array structure manually).

The only trouble is, I see the only place where arrays are appended (via adding
to the length) is in the rebalance function.  This seems to coincide with
another bug report (bug 3898) but the array starts out as a static array, so
unless the stack frame is heap allocated (which it should *not* be), the append
patch should work properly.

I will create some patches to disable the cache and the whole array stomping
fix, and see if either of those makes the problem go away.  If not, then we
have to look elsewhere.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to