RESOLVED FIXED 22753
Reproducible global object leak caused by setInterval 
https://bugs.webkit.org/show_bug.cgi?id=22753
Summary Reproducible global object leak caused by setInterval
Oliver Hunt
Reported 2008-12-09 00:39:25 PST
I have discovered a reproducible global object leak (a valuable property of our GC: when you leak a global object, it takes very little time for maths to become ludicrously expensive and my browsing patterns show tihs really quickly. Because all i look at are js raytracers :D ) Steps to reproduce: 1. Start webkit 2. Open caches window 3. Navigate to http://ejohn.org/apps/processing.js/examples/basic/noisewave.html 4. Navigate to another page (say google.com) 5. Close browser window 6. Force GC a few times Results: We end up with 2 global objects leaked, probably due to the one protected function that hangs around indefinitely. The global object contained by that function, then history probably holds onto all the other global objects, and subsequently everything else.
Attachments
reduction (280 bytes, text/html)
2008-12-09 02:31 PST, Alexey Proskuryakov 		no flags
Details
Proposed patch (1003 bytes, patch)
2008-12-09 05:42 PST, Dmitry Titov 		darin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Oliver Hunt
Comment 1 2008-12-09 00:44:43 PST
<rdar://problem/6429894>
Alexey Proskuryakov
Comment 2 2008-12-09 00:46:35 PST
What version of WebKit are you seeing this with?
Oliver Hunt
Comment 3 2008-12-09 00:51:07 PST
r39131, but i was seeing this from a revision earlier today and updated to verify it still existed in tot
Alexey Proskuryakov
Comment 4 2008-12-09 02:08:48 PST
The leaking protected object is a setInterval() callback in processing.js. There is no leak in r38860, so this is likely to be a regression from DOMTimer refactoring.
Alexey Proskuryakov
Comment 5 2008-12-09 02:31:11 PST
Created attachment 25879 [details] reduction
Dmitry Titov
Comment 6 2008-12-09 05:21:10 PST
Not enough calls to stopActiveDOMObjects(). In this case, the suspended CachedPages are cleared when window is closed. This code path never calls stopActiveDOMObjects() and it caused live JS wrappers to stay alive. After window close, the cached pages are cleared and it seems Document::detach() is a good place to stop active objects. I hope documents can not 'attach' back.
Dmitry Titov
Comment 7 2008-12-09 05:42:00 PST
Created attachment 25883 [details] Proposed patch
Dmitry Titov
Comment 8 2008-12-10 10:50:40 PST
Working on a test. Will add as a separate patch.
Dmitry Titov
Comment 9 2008-12-10 13:08:52 PST
Can't create a test because DumpRenderTree has the page cache disabled. The known way to repro the leak is when CachedPages are destroyed.
Darin Adler
Comment 10 2008-12-10 14:23:41 PST
Comment on attachment 25883 [details] Proposed patch Is it correct behavior to stop XMLHttpRequest in this case? I'll assume the answer is yes and say r=me
Oliver Hunt
Comment 11 2008-12-10 18:14:21 PST
Committing to http://svn.webkit.org/repository/webkit/trunk ... M WebCore/ChangeLog M WebCore/dom/Document.cpp Committed r39193
Dmitry Titov
Comment 12 2008-12-11 01:05:28 PST
added a regression test - bug 22806
Note You need to log in before you can comment on or make changes to this bug.