WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
REOPENED
Bug 164797
js/dom/domjit-function-get-element-by-id-licm.html and js/dom/domjit-function-get-element-by-id-changed.html are flaky timeouts
https://bugs.webkit.org/show_bug.cgi?id=164797
Summary
js/dom/domjit-function-get-element-by-id-licm.html and js/dom/domjit-function...
Ryan Haddad
Reported
2016-11-15 14:48:31 PST
js/dom/domjit-function-get-element-by-id-licm.html and js/dom/domjit-function-get-element-by-id-changed.html are flaky timeouts
https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK2%20(Tests)/r208747%20(16237)/results.html
http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=js%2Fdom%2Fdomjit-function-get-element-by-id-changed.html
http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=js%2Fdom%2Fdomjit-function-get-element-by-id-licm.html
Attachments
mark tests as flaky
(1.84 KB, patch)
2016-11-15 15:19 PST
,
Yusuke Suzuki
saam
: review+
commit-queue
: commit-queue-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Ryan Haddad
Comment 1
2016-11-15 14:50:05 PST
Flakiness dashboard isn't updating at the moment, so I'll try to gather some data on this manually.
Ryan Haddad
Comment 2
2016-11-15 14:50:32 PST
js/dom/domjit-function-get-element-by-id-changed.html timeout on El Capitan Debug WK2:
https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK2%20(Tests)/r208746%20(9448)/results.html
Ryan Haddad
Comment 3
2016-11-15 14:50:32 PST
js/dom/domjit-function-get-element-by-id-changed.html timeout on El Capitan Debug WK2:
https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK2%20(Tests)/r208746%20(9448)/results.html
Ryan Haddad
Comment 4
2016-11-15 14:50:54 PST
Tests were added with
https://trac.webkit.org/changeset/208412
Yusuke Suzuki
Comment 5
2016-11-15 15:00:00 PST
I guess this becomes flaky after
r208588
is landed, correct? If so, I think this is due to the following reason. The performance of the both tests rely on PureGetById. But PureGetById is reverted recently in
r208588
. Then, this revert makes the both tests flaky. Once PureGetById patch is relanded OR this change[1] is landed, I believe the both tests becomes unflaky. Until PureGetById patch is relanded or impure object patch[1] is landed, I think making the both tests TIMEOUT or SKIP is better. What do you think of? [1]:
https://bugs.webkit.org/show_bug.cgi?id=164175
Ryan Haddad
Comment 6
2016-11-15 15:05:27 PST
I'm alright with marking them as flaky for the time being while we wait for the patch referenced above is landed.
Yusuke Suzuki
Comment 7
2016-11-15 15:19:05 PST
Created
attachment 294886
[details]
mark tests as flaky
WebKit Commit Bot
Comment 8
2016-11-16 12:39:47 PST
Comment on
attachment 294886
[details]
mark tests as flaky Rejecting
attachment 294886
[details]
from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'apply-attachment', '--no-update', '--non-interactive', 294886, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: y', '--force', '--reviewer', u'Saam Barati']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Parsed 2 diffs from patch file(s). patching file LayoutTests/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file LayoutTests/TestExpectations Hunk #1 FAILED at 985. 1 out of 1 hunk FAILED -- saving rejects to file LayoutTests/TestExpectations.rej Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Saam Barati']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Full output:
http://webkit-queues.webkit.org/results/2527044
Yusuke Suzuki
Comment 9
2016-11-16 13:02:22 PST
Committed
r208807
: <
http://trac.webkit.org/changeset/208807
>
Ryan Haddad
Comment 10
2016-11-18 14:27:26 PST
Reopening because the flaky expectation for these tests was removed, but they are still flaky.
Ryan Haddad
Comment 11
2016-11-18 14:28:02 PST
(In reply to
comment #10
)
> Reopening because the flaky expectation for these tests was removed, but > they are still flaky.
https://trac.webkit.org/changeset/208824/trunk/LayoutTests/TestExpectations
Yusuke Suzuki
Comment 12
2016-11-18 14:28:34 PST
(In reply to
comment #11
)
> (In reply to
comment #10
) > > Reopening because the flaky expectation for these tests was removed, but > > they are still flaky. > >
https://trac.webkit.org/changeset/208824/trunk/LayoutTests/TestExpectations
Oops, I accidentally removed it. I'll land it soon.
Ryan Haddad
Comment 13
2016-11-18 14:32:10 PST
Marked as flaky again in
http://trac.webkit.org/projects/webkit/changeset/208900
Yusuke Suzuki
Comment 14
2016-11-18 14:32:59 PST
(In reply to
comment #13
)
> Marked as flaky again in >
http://trac.webkit.org/projects/webkit/changeset/208900
Thanks so much.
Alexey Proskuryakov
Comment 15
2016-12-08 13:33:53 PST
This still happens on the bots very frequently. It seems like the tests are just ultra slow in debug - they take around 30 seconds consistently.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug