|Summary:||fast/js/date-proto-generic-invocation breaks another test|
|Product:||WebKit||Reporter:||Shinichiro Hamaji <hamaji>|
|Component:||Tools / Tests||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Critical||CC:||darin, dimich, eric, mrowe, sam, yutak|
|Version:||528+ (Nightly build)|
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 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.