<rdar://problem/20848288> We've got about 750 KB worth of WeakBlocks leaked on the leaks bot right now. Boo.
Created attachment 252547 [details] Patch
Comment on attachment 252547 [details] Patch I think we return here and use std::unique_ptr for this. It would remove the need to explicitly call WeakBlock::destroy in Heap::sweepNextLogicallyEmptyWeakBlock. I know this is low-level code and std::unique_ptr might seem out of place, but I think it would cleanly prevent a mistake like this one!
(In reply to comment #2) > Comment on attachment 252547 [details] > Patch > > I think we return here and use std::unique_ptr for this. It would remove the > need to explicitly call WeakBlock::destroy in > Heap::sweepNextLogicallyEmptyWeakBlock. I know this is low-level code and > std::unique_ptr might seem out of place, but I think it would cleanly > prevent a mistake like this one! That's not a bad idea. I glossed over it because I assumed WeakBlocks were aligned to their block size, but it turns out that they're just plain fastMalloc()'ed objects. With a little care, we can fix these up to live in unique_ptr. Landing this right away to unscrew leaks bot though.
> I think we return here and use std::unique_ptr for this. It would remove the > need to explicitly call WeakBlock::destroy in > Heap::sweepNextLogicallyEmptyWeakBlock. I know this is low-level code and > std::unique_ptr might seem out of place, but I think it would cleanly > prevent a mistake like this one! I agree. Once upon a time it was not practical to unique_ptr these objects, but now it should be pretty trivial.
Comment on attachment 252547 [details] Patch Clearing flags on attachment: 252547 Committed r183938: <http://trac.webkit.org/changeset/183938>
All reviewed patches have been landed. Closing bug.