503304 - using delete on a new (GC*) object where object doesn't inherit from GCObject results in hard to debug crashes

Status: VERIFIED FIXED

(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P5)

Description

[Tommy Reilly]

Should be easy to assert that the address passed to FixedMalloc free didn't come from FixedMalloc::Alloc.

Comment 1

[Lars T Hansen]

(poaching)

Comment 2

[Lars T Hansen]

Attachment: Patch

Here's a basic solution.

Two refinements are easily imagined:

 - a more sophisticated data structure to track large blocks to make it less
   likely that the linear scan will make debug builds really slow

 - we could assert that the small-object pointer points to and object (not just
   into one) and that that object is not free, not simply that it points into
   a block's memory area.

Comment 3

[Tommy Reilly]

Comment on attachment 414274 [details] [diff] [review]
Patch

My plan for large blocks was to just assert that the GCHeap had a HeapBlock inUse at that address that was the right size, much simpler, almost as effective.  This technique is a little better as it guards against coincidental positives from other GCHeap clients.

Comment 4

[Lars T Hansen]

redux changeset 3229:6e00ccd98704

Comment 5

[Lars T Hansen]

Reopening because it probably needs a tweak so as not to upset the sampler.

Comment 6

[Lars T Hansen]

Attachment: Fall back on non-allocation if AVMPLUS_SAMPLER is defined

Comment 7

[Lars T Hansen]

redux changeset:   3329:d7162814f1f5

Comment 8

[Chris Peyer]

Engineering work item.  Marking as verified.