Test fast/dom/gc-10.html is behaving badly, calling dump() in DumpRenderTree twice, thus dumping render tree twice and calling gtk_main_quit twice as well, causing such messages being output on stderr: gtk_main_quit: assertion `main_loop != NULL' failed It may seem as an issue in GTK's DumpRenderTree, but there's more to it. The test has side effects, astonishingly causing some tests that are expected to fail to actually pass in some weird and benign way. As far as I've looked into the issue the test itself is behaving incorrectly. I'm including a possibility of the test failing on other ports as well after it is fixed or rather refactored to work properly (as I'm pretty sure it currently isn't).
Committed r117488: <http://trac.webkit.org/changeset/117488>
CC-ing ggaren, olliej and weinig as they've been poking around this test since it's been introduced in r19013. I don't think this test is testing the problem properly. For starters, at least when the test is run in GTK's DumpRenderTree, the frame is never reloaded, while the test in the current form indicates it should be reloaded three times. The test ends when the _main frame_ is loaded, making the object count before 399 and after 402, so the test passes. After making some changes to the test so the frame is actually reloaded three times the test fails in the object count check, counting 449 objects before and 635 objects after (number of reloads does not affect the object counts). The test was refactored by calling waitUntilDone at the start of the test, reloading the frame three times and then performing the object count check and ending the test. Also, a smaller annoyance, i think it would make sense to make this test dump text instead of render tree. On the other hand, there might be a detail I'm missing here and the test is running as it is supposed to, meaning there's a problem in the GTK's DumpRenderTree.
> After making some changes to the test so the frame is actually reloaded three times the test fails in the object count check, counting 449 objects before and 635 objects after (number of reloads does not affect the object counts). This sounds like a possible memory leak. You can test the memory leak theory by doing a few reloads before taking your baseline number, and then measuring a series of object counts after a series of reloads, to see if they're increasing. > Also, a smaller annoyance, i think it would make sense to make this test dump text instead of render tree. Agreed.
The test is passing now, i.e. no leaks over the threshold are reported. The test is being changed so it dumps text in bug #119944.