This only happens on 10.4 PPC and does not happen on 10.5 $AVM regress/bug_515935.abc Actual test is that exitcode 128 is returned. PASSED! Implementation limit exceeded: attempting to allocate too-large object error: out of memory avmshell_d_104_ppc(9473) malloc: *** Deallocation of a pointer not malloced: 0x2740e000; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug This started happening with TR-ARGO rev 3900 http://asteam.macromedia.com/hg/tamarin-redux-argo/rev/3900 http://hg.mozilla.org/tamarin-redux/rev/4245

What's happening is that we're aborting due to a too large allocation and leaking some large allocations which GCHeap isn't handling it properly.

10.4 doesn't use virtual memory so when Large objects are leaked they need to be handled separately in FreeAll. It could be argued that we shouldn't be using VM API's on 10.4 but the only reason we don't use them is that they don't support decommit/recommit and we don't do that with the Large object allocations.

Comment on attachment 437548 [details] [diff] [review] fixes 10.4 issue That assert looks aggressive since I had assumed that leaks could happen anywhere by code simply not freeing a large object, but you know best.

The precedent set in GCHeap::DestroyInstance is that we assert on leaks unless we're aborting

tamarin-redux-argo: changeset: 3952:99b8651e2683 tamarin-redux: changeset: 4339:99b8651e2683

Verified that the testcase is no longer failing on 10.4 in tr-argo 3952