RESOLVED FIXED Bug 82993
chromium: fast/dom/error-to-string-stack-overflow.html is failing after v8 roll to 3.10.0.2
https://bugs.webkit.org/show_bug.cgi?id=82993
Summary chromium: fast/dom/error-to-string-stack-overflow.html is failing after v8 ro...
Dirk Pranke
Reported 2012-04-02 18:39:02 PDT
See http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=fast%2Fdom%2Ferror-to-string-stack-overflow.html%2Csvg%2Fcustom%2Ftext-ctm.svg&builder=Webkit%20Win It looks like the v8 roll in http://codereview.chromium.org/9950056 caused this, so I'm going to roll it out. I apologize for the lack of notification; it looks like this has been failing all day but we didn't have a webkit gardener so no one noticed. -- Dirk
Attachments
Adjust test expectation to include the line number of the exception. (1.44 KB, patch)
2012-04-03 03:00 PDT, Ulan Degenbaev
no flags
Update LayoutTests/platform/chromium/test_expectations.txt to ignore the test (2.04 KB, patch)
2012-04-03 03:31 PDT, Ulan Degenbaev
haraken: review+
webkit.review.bot: commit-queue-
Rebased (2.09 KB, patch)
2012-04-03 06:02 PDT, Ulan Degenbaev
no flags
Ulan Degenbaev
Comment 1 2012-04-03 02:30:52 PDT
The difference between the expected(-) and the actual(+) in Linux 64-bit: -CONSOLE MESSAGE: Uncaught RangeError: Maximum call stack size exceeded +CONSOLE MESSAGE: line 14: Uncaught RangeError: Maximum call stack size exceeded Regression test for We started reporting the line number with V8 3.10.0.2. Should we adjust the test expectations for Linux 64-bit (platform/chromium-linux/)? Note that the test expectations for Linux 32-bit already have the correct line number: CONSOLE MESSAGE: line 14: Uncaught RangeError: Maximum call stack size exceeded
Ulan Degenbaev
Comment 2 2012-04-03 03:00:52 PDT
Created attachment 135295 [details] Adjust test expectation to include the line number of the exception. This can be landed after V8 3.10.0.3 roll.
Ulan Degenbaev
Comment 3 2012-04-03 03:31:17 PDT
Created attachment 135300 [details] Update LayoutTests/platform/chromium/test_expectations.txt to ignore the test Looks like the correct sequence is to land this patch with updated LayoutTests/platform/chromium/test_expectations.txt and then roll V8. Could someone please review and land this patch for me?
Kentaro Hara
Comment 4 2012-04-03 04:10:47 PDT
Comment on attachment 135300 [details] Update LayoutTests/platform/chromium/test_expectations.txt to ignore the test Looks good!
WebKit Review Bot
Comment 5 2012-04-03 05:52:50 PDT
Comment on attachment 135300 [details] Update LayoutTests/platform/chromium/test_expectations.txt to ignore the test Rejecting attachment 135300 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: queue/Source/WebKit/chromium/third_party/sfntly/cpp/src --revision 128 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' 42>At revision 128. ________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' ________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' Updating webkit projects from gyp files... Full output: http://queues.webkit.org/results/12321126
Kentaro Hara
Comment 6 2012-04-03 05:54:38 PDT
Would you please rebase your patch with the latest WebKit trunk and then re-upload it, just in case?
Ulan Degenbaev
Comment 7 2012-04-03 06:02:54 PDT
Created attachment 135317 [details] Rebased Rebased to avoid merge conflict.
WebKit Review Bot
Comment 8 2012-04-03 06:40:16 PDT
Comment on attachment 135317 [details] Rebased Clearing flags on attachment: 135317 Committed r113029: <http://trac.webkit.org/changeset/113029>
WebKit Review Bot
Comment 9 2012-04-03 06:40:22 PDT
All reviewed patches have been landed. Closing bug.
Dirk Pranke
Comment 10 2012-04-03 11:53:53 PDT
Oh, I'm sorry I rolled this out just for a rebaseline :(. If I had been sharper last night I would've noticed. Glad it's fixed now, and sorry for the inconvenience!
Ulan Degenbaev
Comment 11 2012-04-04 01:02:03 PDT
(In reply to comment #10) > Oh, I'm sorry I rolled this out just for a rebaseline :(. If I had been sharper last night I would've noticed. Glad it's fixed now, and sorry for the inconvenience! No problem, we should have updated the expectations before rolling in.
Note You need to log in before you can comment on or make changes to this bug.