Bug 27801 - [WML] Running WML tests in random order multiple times exposes subtle bugs
Summary: [WML] Running WML tests in random order multiple times exposes subtle bugs
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nikolas Zimmermann
URL:
Keywords:
Depends on:
Blocks: 20393
  Show dependency treegraph
 
Reported: 2009-07-29 04:27 PDT by Nikolas Zimmermann
Modified: 2009-07-29 06:20 PDT (History)
2 users (show)

See Also:


Attachments
Initial patch (11.80 KB, patch)
2009-07-29 04:39 PDT, Nikolas Zimmermann
manyoso: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolas Zimmermann 2009-07-29 04:27:02 PDT
As the summary says running "run-webkit-tests fast/wml http/tests/wml wml --random" exposes some bug:
* fast/wml/err-multi-access.wml (related to bug 27721, can't be fixed at the moment, deck access control is broken) -> creates different error positions upon consecutive runs (line 6, line 5, etc)

* wml/enter-first-card-with-events.html doesn't work properly on consecutive runs. We have to take special care of detecting the end of the test here -> not resetting the page state was not a good idea, instead it hided a bug that we don't preserve the current history item on clearWMLPageHistory()

* Some assertions in removedFromDocument regarding parentNode() fire, upon GC collection at random spots. Don't ASSERT(parent()) there. It was superflous anyway, as we check the return value

Fixing the latter problem allows us to simplify WMLTestCase.js again and to run random order testing (almost only fast/wml/err-multi-access.wml left to fix there).
Comment 1 Nikolas Zimmermann 2009-07-29 04:39:24 PDT
Created attachment 33711 [details]
Initial patch
Comment 2 Adam Treat 2009-07-29 06:19:37 PDT
Comment on attachment 33711 [details]
Initial patch

Talked it over with Niko in chat and showed me the backtrace of crashes caused by gc collect in middle of reload triggering the tear down with some elements with parent == 0.  Looks good.
Comment 3 Nikolas Zimmermann 2009-07-29 06:20:03 PDT
Landed in r46539.