Bug 86771 - [Gtk] fast/dom/gc-10.html behaves badly
Summary: [Gtk] fast/dom/gc-10.html behaves badly
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk, LayoutTestFailure
Depends on:
Blocks:
 
Reported: 2012-05-17 13:13 PDT by Zan Dobersek
Modified: 2013-08-17 07:07 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zan Dobersek 2012-05-17 13:13:58 PDT
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).
Comment 1 Zan Dobersek 2012-05-17 13:29:59 PDT
Committed r117488: <http://trac.webkit.org/changeset/117488>
Comment 2 Zan Dobersek 2012-05-18 10:01:10 PDT
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.
Comment 3 Geoffrey Garen 2012-05-18 10:21:33 PDT
> 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.
Comment 4 Zan Dobersek 2013-08-17 07:07:29 PDT
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.