Summary: | Memory leak due to circular reference Document->DOMTimer->ScheduledAction->[JS objects]->Document | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dmitry Titov <dimich> | ||||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ap | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
Dmitry Titov
2008-12-06 04:54:36 PST
Created attachment 25813 [details]
proposed fix
Created attachment 25814 [details] repro file repro file by ap@webkit.org. Set a breakpoint at DOMTimer::stop and ~DOMTimer. Load the file and then close the window. You should see stop() called, then ~DOMTimer() called when Document is destroyed. Before the fix applied, you see only stop(). After the patch with fix applied, both are invoked. Comment on attachment 25813 [details]
proposed fix
r=me
I don't think the added null check in DOMTimer destructor is useful, but it isn't harmful either.
Committed revision 39066. Can we make a test case for this? (In reply to comment #5) > Can we make a test case for this? I think it's doable by adding a method to LayoutTestController (getJSObjectCount() which will do GCController::collect first). This way, it's possible to navigate say iframe to a test page and back and then see the number of objects alive. But perhaps there is a simpler way that I don't see? |