57678 2011-04-01 16:01:14 -0700 slow or flaky workers test under new-run-webkit-tests 2011-04-19 20:35:47 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 1 dpranke webkit-unassigned commit-queue dimich levin oldest_to_newest 378164 0 dpranke 2011-04-01 16:01:14 -0700 This test seems to take more than six seconds to complete; this is probably not a good thing. 378898 1 dimich 2011-04-04 11:16:57 -0700 I see this test is actually SKIP now in platform/mac/test_expectations.txt. Is it possible to add more info as for why it is SKIP (a link to failed results would be useful). 378914 2 dpranke 2011-04-04 11:33:20 -0700 I only marked this as a SKIP on friday because I was trying to get the mac NRWT bot to run cleanly. In my experience that test was taking anywhere from a few seconds to more than 35 to complete (timeouts). Unfortunately, there is no mac NRWT bot yet, so I can't point you to logs. It's easy enough for me to reproduce. Is there something I can get for you that would be helpful? 378924 3 dimich 2011-04-04 11:46:42 -0700 (In reply to comment #2) > It's easy enough for me to reproduce. Is there something I can get for you that would be helpful? I run it numerous times (in RWT and NRWT) and it takes <1s with no timeouts. So I'd like to figure out what's different. Do you run debug/release? what OS? is it only repros under NRWT or RWT also? What is exact command you run? etc. 378930 4 dpranke 2011-04-04 11:53:30 -0700 (In reply to comment #3) > (In reply to comment #2) > > It's easy enough for me to reproduce. Is there something I can get for you that would be helpful? > > I run it numerous times (in RWT and NRWT) and it takes <1s with no timeouts. So I'd like to figure out what's different. Do you run debug/release? what OS? is it only repros under NRWT or RWT also? What is exact command you run? etc. Mac SL release, upstream mac DumpRenderTree (not chromium), just run as "new-run-webkit-tests --worker-model=inline fast", for example. I am rebuilding against tip-of-tree right now and will confirm that it still happens. 378961 5 dpranke 2011-04-04 12:30:04 -0700 (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > It's easy enough for me to reproduce. Is there something I can get for you that would be helpful? > > > > I run it numerous times (in RWT and NRWT) and it takes <1s with no timeouts. So I'd like to figure out what's different. Do you run debug/release? what OS? is it only repros under NRWT or RWT also? What is exact command you run? etc. > > Mac SL release, upstream mac DumpRenderTree (not chromium), just run as "new-run-webkit-tests --worker-model=inline fast", for example. > > I am rebuilding against tip-of-tree right now and will confirm that it still happens. Okay, it is still timing out, but only when I run the entire set of tests. Exactly command line is: % new-run-webkit-tests --print default,config --worker-model=inline 378963 6 dpranke 2011-04-04 12:32:12 -0700 Note that the test is definitely flaky, because when NRWT retries the test, it passes. This suggests to me that some previous test is messing with the state. 378982 7 dpranke 2011-04-04 12:52:25 -0700 Hmm. Probably better to mark this as a flaky PASS/TIMEOUT test, since it looks like it doesn't always timeout and that way we'll eventually be able to get better data on it from the flakiness dashboard. 379117 8 dpranke 2011-04-04 15:10:57 -0700 interesting .. if you run with --time-out-ms=35000 (to match the ORWT default), several tests are reliably failing with a timeout on notifyDone() inside the test. 379161 9 dpranke 2011-04-04 16:04:59 -0700 Okay, after I adjusted the default test timeout on NRWT to match ORWT, I'm seeing the following tests time out occasionally inside DRT themselves, when run as part of the whole test suite: fast/workers/dedicated-worker-lifecycle.html fast/workers/shared-worker-frame-lifecycle.html fast/workers/shared-worker-lifecycle.html fast/workers/storage/interrupt-database.html fast/workers/worker-close-more.html fast/workers/worker-lifecycle.html To reproduce, run the command line as before. For now I will check in some test expectation suppressions so that things will run cleanly while we hunt this down. I've updated the subject accordingly as well. 379216 10 levin 2011-04-04 16:47:50 -0700 (In reply to comment #9) > Okay, after I adjusted the default test timeout on NRWT to match ORWT, I'm seeing the following tests time out occasionally inside DRT themselves, when run as part of the whole test suite: > > fast/workers/dedicated-worker-lifecycle.html > fast/workers/shared-worker-frame-lifecycle.html > fast/workers/shared-worker-lifecycle.html > fast/workers/storage/interrupt-database.html > fast/workers/worker-close-more.html > fast/workers/worker-lifecycle.html > > To reproduce, run the command line as before. For now I will check in some test expectation suppressions so that things will run cleanly while we hunt this down. > > I've updated the subject accordingly as well. So they timeout with NRWT but not with ORWT? 385275 11 dimich 2011-04-13 14:59:49 -0700 Might be related to bug 57090. One of the tests listed in this bug as flaky actually had a race condition in it. 388878 12 90271 dimich 2011-04-19 16:10:19 -0700 Created attachment 90271 Patch 388881 13 dimich 2011-04-19 16:13:03 -0700 I run: new-run-webkit-tests --print default,config --worker-model=inline multiple times and didn't see a single flake on those worker tests after landing fix for bug 67090. I think the better termination sequence and removing the document.write() usage form utility script fixed that. I did see failures on my machine before that fix. 388938 14 90271 levin 2011-04-19 17:28:58 -0700 Comment on attachment 90271 Patch If it has problems, it can easily be reverted. 389031 15 commit-queue 2011-04-19 20:33:04 -0700 The commit-queue encountered the following flaky tests while processing attachment 90271: http/tests/misc/favicon-loads-with-icon-loading-override.html bug 58412 (author: alice.liu@apple.com) http/tests/media/video-load-twice.html bug 51138 (authors: eric.carlson@apple.com and jamesr@chromium.org) The commit-queue is continuing to process your patch. 389032 16 90271 commit-queue 2011-04-19 20:35:41 -0700 Comment on attachment 90271 Patch Clearing flags on attachment: 90271 Committed r84335: <http://trac.webkit.org/changeset/84335> 389033 17 commit-queue 2011-04-19 20:35:47 -0700 All reviewed patches have been landed. Closing bug. 90271 2011-04-19 16:10:19 -0700 2011-04-19 20:35:41 -0700 Patch bug-57678-20110419161017.patch text/plain 1807 dimich U3VidmVyc2lvbiBSZXZpc2lvbjogODQyODUKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5n ZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxvZwppbmRleCAyYjc0M2ZiZGQyMmI3Y2E3NzdmYzE1 M2Y0YmI1ZWQzZTVjZDU0ZDc3Li5jZWM1NzU5YjQ0Yzc3NjVkMmMyYzA0YTVlNDA5YjZiZTA0MDUw M2Q5IDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMv Q2hhbmdlTG9nCkBAIC0xLDMgKzEsMTQgQEAKKzIwMTEtMDQtMTkgIERtaXRyeSBUaXRvdiAgPGRp bWljaEBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISku CisKKyAgICAgICAgbmV3LXJ1bi13ZWJraXQtdGVzdHM6IHJlbW92ZSBmb3JtZXJseSBmbGFrZXkg dGVzdHMgZm9ybSB0ZXN0X2V4cGVjdGF0aW9ucy4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtp dC5vcmcvc2hvd19idWcuY2dpP2lkPTU3Njc4CisKKyAgICAgICAgVGVzdHMgZml4ZWQgYnkgaHR0 cDovL3RyYWMud2Via2l0Lm9yZy9jaGFuZ2VzZXQvODM5MDAKKworICAgICAgICAqIHBsYXRmb3Jt L21hYy90ZXN0X2V4cGVjdGF0aW9ucy50eHQ6CisKIDIwMTEtMDQtMTkgIENocmlzIFJvZ2VycyAg PGNyb2dlcnNAZ29vZ2xlLmNvbT4KIAogICAgICAgICBVbnJldmlld2VkLgpkaWZmIC0tZ2l0IGEv TGF5b3V0VGVzdHMvcGxhdGZvcm0vbWFjL3Rlc3RfZXhwZWN0YXRpb25zLnR4dCBiL0xheW91dFRl c3RzL3BsYXRmb3JtL21hYy90ZXN0X2V4cGVjdGF0aW9ucy50eHQKaW5kZXggMGM3YWQxODU3YThi YTk3MWY0ZWYyZjZmOGQzNWExNGQ0N2U0OWI4My4uMDExNTNjNzliMDlkMDgzYWJlODY4YmQ3ZGQ0 NTgyOWI5MGFkYjgxYiAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvcGxhdGZvcm0vbWFjL3Rlc3Rf ZXhwZWN0YXRpb25zLnR4dAorKysgYi9MYXlvdXRUZXN0cy9wbGF0Zm9ybS9tYWMvdGVzdF9leHBl Y3RhdGlvbnMudHh0CkBAIC02MCwxNCArNjAsNiBAQAogLy8gT3VyIHNsb3cgdGVzdHMsIGluIGFs cGhhYmV0aWNhbCBvcmRlci4KIEJVR1dLNTc2NzIgOiBodHRwL3Rlc3RzL2xvY2FsL2ZpbGVhcGkv c2VuZC1zbGljZWQtZHJhZ2dlZC1maWxlLmh0bWwgPSBURVhUIFBBU1MKIAotLy8gRmxha3kgdGVz dHMgdGhhdCBhcHBlYXIgdG8gYmUgc3BvcmFkaWNhbGx5IHRpbWluZyBvdXQuCi1CVUdXSzU3Njc4 IDogZmFzdC93b3JrZXJzL2RlZGljYXRlZC13b3JrZXItbGlmZWN5Y2xlLmh0bWwgPSBURVhUIFBB U1MKLUJVR1dLNTc2NzggOiBmYXN0L3dvcmtlcnMvc2hhcmVkLXdvcmtlci1mcmFtZS1saWZlY3lj bGUuaHRtbCA9IFRFWFQgUEFTUwotQlVHV0s1NzY3OCA6IGZhc3Qvd29ya2Vycy9zaGFyZWQtd29y a2VyLWxpZmVjeWNsZS5odG1sID0gVEVYVCBQQVNTCi1CVUdXSzU3Njc4IDogZmFzdC93b3JrZXJz L3N0b3JhZ2UvaW50ZXJydXB0LWRhdGFiYXNlLmh0bWwgPSBURVhUIFBBU1MKLUJVR1dLNTc2Nzgg OiBmYXN0L3dvcmtlcnMvd29ya2VyLWNsb3NlLW1vcmUuaHRtbCA9IFRFWFQgUEFTUwotQlVHV0s1 NzY3OCA6IGZhc3Qvd29ya2Vycy93b3JrZXItbGlmZWN5Y2xlLmh0bWwgPSBURVhUIFBBU1MKLQog QlVHV0s1Nzc5OSA6IHN0b3JhZ2UvZG9tc3RvcmFnZS9sb2NhbHN0b3JhZ2Uvc3RvcmFnZXRyYWNr ZXIvc3RvcmFnZS10cmFja2VyLTQtY3JlYXRlLmh0bWwgPSBURVhUIFBBU1MKIEJVR1dLNTc3OTkg OiBzdG9yYWdlL2RvbXN0b3JhZ2UvbG9jYWxzdG9yYWdlL3N0b3JhZ2V0cmFja2VyL3N0b3JhZ2Ut dHJhY2tlci01LWRlbGV0ZS1vbmUuaHRtbCA9IFRFWFQgUEFTUwogCg==