fast/js/date-proto-generic-invocation breaks another test

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Shinichiro Hamaji]

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

[Shinichiro Hamaji]

Created attachment 42848 [details]
Patch v1

[Shinichiro Hamaji]

Created attachment 42849 [details]
Patch v2

[Sam Weinig]

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.

[Shinichiro Hamaji]

(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).

[Eric Seidel (no email)]

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]

[Yuta Kitamura]

(In reply to comment #5)
> Is this also the reason for this bot failure?

I think so.

[Shinichiro Hamaji]

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?

[Darin Adler]

Sam, can you suggest a better approach to fixing the bug?

[Shinichiro Hamaji]

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...

[Sam Weinig]

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.

[Sam Weinig]

Fixed in r51523.