http://d.puremagic.com/issues/show_bug.cgi?id=3929
Steven Schveighoffer <schvei...@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer <schvei...@yahoo.com> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------