Bug 31286 - fast/js/date-proto-generic-invocation breaks another test
Summary: fast/js/date-proto-generic-invocation breaks another test
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Critical
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-09 22:39 PST by Shinichiro Hamaji
Modified: 2009-11-30 17:19 PST (History)
6 users (show)

See Also:


Attachments
Patch v1 (1.67 KB, patch)
2009-11-09 22:40 PST, Shinichiro Hamaji
no flags Details | Formatted Diff | Diff
Patch v2 (1.78 KB, patch)
2009-11-09 23:23 PST, Shinichiro Hamaji
sam: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Shinichiro Hamaji 2009-11-09 22:39:39 PST
fast/js/date-proto-generic-invocation.html creates a toString() which raises an exception and this makes fast/js/global-constructors.html fail.

The easiest way to re-produce this fail is

./WebKitTools/Scripts/run-webkit-tests  --release LayoutTests/fast/js/date-proto-generic-invocation.html LayoutTests/fast/js/global-constructors.html

This is the reason of the commit-queue failure

https://bugs.webkit.org/show_bug.cgi?id=30423#c11
Comment 1 Shinichiro Hamaji 2009-11-09 22:40:54 PST
Created attachment 42848 [details]
Patch v1
Comment 2 Shinichiro Hamaji 2009-11-09 23:23:22 PST
Created attachment 42849 [details]
Patch v2
Comment 3 Sam Weinig 2009-11-09 23:34:05 PST
Comment on attachment 42849 [details]
Patch v2

This seems to just be papering over another issue. It is important to understand why this test is failing.
Comment 4 Shinichiro Hamaji 2009-11-10 00:05:22 PST
(In reply to comment #3)
> (From update of attachment 42849 [details])
> This seems to just be papering over another issue. It is important to
> understand why this test is failing.

I see. Yeah, it would be better to make test harness free from context leakage. Unfortunately, I think I don't have enough knowledge on this area to fix this issue soon. I hope someone fix this quickly as this issue prevents landing patches which add tests before fast/js/date-proto-generic-invocation.html (once one more test is added, these two tests will run in same DumpRenderTree).
Comment 5 Eric Seidel (no email) 2009-11-13 14:43:33 PST
Is this also the reason for this bot failure?

http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r50968%20(7227)/results.html
--- layout-test-results/fast/js/global-constructors-expected.txt	2009-11-13 14:09:05.000000000 -0800
+++ layout-test-results/fast/js/global-constructors-actual.txt	2009-11-13 14:09:05.000000000 -0800
@@ -1,182 +1,10 @@
+CONSOLE MESSAGE: line 8: TypeError: Type error
 This test documents our set of global constructors we expose on the window object (FF and Opera don't expose them on the window, btw). This also checks to make sure than any constructor attribute we expose has the expected constructor type.
 
 On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
 
 
-PASS Attr.toString() is '[object AttrConstructor]'
[snip]
Comment 6 Yuta Kitamura 2009-11-13 19:42:18 PST
(In reply to comment #5)
> Is this also the reason for this bot failure?

I think so.
Comment 7 Shinichiro Hamaji 2009-11-16 00:04:26 PST
Yeah, I think this is the same bug. Interestingly, this this failure isn't happening for now. It seems that this fail happens only when date-proto-generic-invocation is the first test for a DumpRenderTree process. For example,

./WebKitTools/Scripts/run-webkit-tests --release LayoutTests/fast/js/date-proto-generic-invocation.html LayoutTests/fast/js/global-constructors.html

is still failing, but

./WebKitTools/Scripts/run-webkit-tests --release LayoutTests/fast/js/date-preserve-milliseconds.html LayoutTests/fast/js/date-proto-generic-invocation.html LayoutTests/fast/js/global-constructors.html

doesn't fail.

I think that's why we aren't seeing this failure in buildbot after the failure Eric mentioned. Anyway, I think we can land blocked patches now. We may want to reduce priority of this bug as this bug may not block other patches, I guess?
Comment 8 Darin Adler 2009-11-16 13:55:03 PST
Sam, can you suggest a better approach to fixing the bug?
Comment 9 Shinichiro Hamaji 2009-11-27 01:27:16 PST
Hmm... this seems to cause failure again for Tiger build bot.

http://build.webkit.org/results/Tiger%20Intel%20Release/r51430%20(6488)/fast/js/global-constructors-pretty-diff.html

I believe this will continue failing until someone add a test before fast/js/date-proto-generic-invocation...
Comment 10 Sam Weinig 2009-11-30 17:12:22 PST
The real issue is that we are sharing the JSClassRef for the LayoutTestController JS object between runs by using a static in LayoutTestController::getJSClass().  The fix is not generate a new JSClassRef each time the method is called. This seems like a deficiency in the JSC API, I will discuss this with Geoff.
Comment 11 Sam Weinig 2009-11-30 17:19:03 PST
Fixed in r51523.