RESOLVED WORKSFORME 256935
WebKitTestRunner --world-leaks reports false positives 
https://bugs.webkit.org/show_bug.cgi?id=256935
Summary WebKitTestRunner --world-leaks reports false positives
Ryan Reno
Reported 2023-05-17 17:44:34 PDT
> run-webkit-tests --world-leaks fast/canvas/webgl/webgl2/bindings.html > run-webkit-tests --world-leaks fast/canvas/webgl/webgl-reload-crash.html These canvas tests will report a leaked document but it is not reproducible from MiniBrowser. If you navigate to the test then go to about:blank and issue a low memory warning followed by showAllDocuments, only the about:blank document and page are live. I tried disabling the BackForwardCache and setting the CacheModel to DocumentBrowser in MiniBrowser to match WKTR but still cannot reproduce the leak. It appears the false positive is indeed due to a leaked document but I think there's something else going on. If you pause the test runner after it gets the list of live documents but before it finishes the test (TestController::didReceiveLiveDocumentsList) then ask for a GC heap dump the leaked document will be collected. Put a breakpoint in Document::~Document and issue the following command: > notifyutil -p com.apple.WebKit.dumpGCHeap While the WKTR process is paused the WebContent process will start a GC in response to the notification which will lead to the last JSEventTarget wrapper to be GC'd which will allow the Document to be destroyed. Something specific to WKTR must be keeping documents alive in some layout tests.
Attachments
Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2023-05-17 17:44:48 PDT
<rdar://problem/109488830>
Alexey Proskuryakov
Comment 2 2023-05-18 15:02:22 PDT
As we use conservative GC, there can never be a guarantee that everything unused is collected.
Ryan Reno
Comment 3 2023-05-18 15:22:39 PDT
Even when doing full, sync GC like we do in this case? (x2)
Alexey Proskuryakov
Comment 4 2023-05-18 16:57:22 PDT
Correct. There can always be some pointer stuck in memory that hasn't been overwritten, or on stack.
Nathan Solomon
Comment 5 2024-10-18 12:12:58 PDT
Pull request: https://github.com/WebKit/WebKit/pull/35441
Ryan Reno
Comment 6 2024-11-12 17:22:54 PST
Nathan's PR shows the analysis he did to scan the stack for document pointers. It's very likely we don't have a very high false positive rate and instead it was a product of the way in which I was testing which made me think there were false positives.
Note You need to log in before you can comment on or make changes to this bug.