When MarkSweepGarbageCollector is dropped (or an Arena drops normally), the destructor for Arena handles the primary byte buffer by calling dealloc(self.buffer, self.layout). Unfortunately, it does not explicitly walk the allocations within the Arena to trigger their respective destructors (drop_in_place).
While basic memory within the arena gets cleaned up, if the GC wrapper contains unmanaged heap data (e.g. String, Vec, or structs managing system resources), those drop routines will never be invoked, severely leaking memory.
Proposed Solution: Update impl Drop for Arena (or perform it before dropping in MarkSweepGarbageCollector) to iterate through the self.last_allocation singly-linked list. For any ArenaHeapItem where !item.is_dropped(), explicitly invoke item.drop() or drop_in_place before finally deallocating the underlying arena buffer.
Could you please assign this issue to me?
When
MarkSweepGarbageCollectoris dropped (or anArenadrops normally), the destructor forArenahandles the primary byte buffer by callingdealloc(self.buffer, self.layout). Unfortunately, it does not explicitly walk the allocations within theArenato trigger their respective destructors (drop_in_place).While basic memory within the arena gets cleaned up, if the GC wrapper contains unmanaged heap data (e.g.
String,Vec, or structs managing system resources), those drop routines will never be invoked, severely leaking memory.Proposed Solution: Update
impl Drop for Arena(or perform it before dropping inMarkSweepGarbageCollector) to iterate through theself.last_allocationsingly-linked list. For anyArenaHeapItemwhere!item.is_dropped(), explicitly invokeitem.drop()ordrop_in_placebefore finally deallocating the underlying arena buffer.Could you please assign this issue to me?