Bug 61932 - jquery/manipulation.html is very slow in debug builds, frequently timing out
Summary: jquery/manipulation.html is very slow in debug builds, frequently timing out
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk, Qt, QtTriaged
Depends on: 90970 90968 90969 90971
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-02 09:06 PDT by Mario Sanchez Prada
Modified: 2014-12-14 21:00 PST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mario Sanchez Prada 2011-06-02 09:06:16 PDT
This test has been observed randomly failing during the last two days at least in the GTK 32-bit only.

This is the output diff when it fails:

--- /home/slave/webkitgtk/gtk-linux-32-debug/build/layout-test-results/jquery/manipulation-expected.txt	2011-06-02 08:24:17.491741296 -0700
+++ /home/slave/webkitgtk/gtk-linux-32-debug/build/layout-test-results/jquery/manipulation-actual.txt	2011-06-02 08:24:17.491741296 -0700
@@ -1,2 +1,2 @@
-ALERT: 473 tests of 473 passed, 0 failed.
+FAIL: Timed out waiting for notifyDone to be called


Stating the obvious, it looks like the messages listener in jquery/resources/helper.js does not get executed some times, because of some reason.

CCing Adam Barth, as the author of the commit introducing this jquery test suite.
Comment 1 Csaba Osztrogonác 2012-05-02 06:17:11 PDT
It fails always on Qt 32 bit debug mode always.
Comment 2 Csaba Osztrogonác 2012-05-02 06:25:46 PDT
It is only a very very slow test, passes with --no-timeout option passed to DRT:

$ time WebKitBuild/Debug/bin/DumpRenderTree LayoutTests/jquery/manipulation.html --no-timeout
ALERT: 473 tests of 473 passed, 0 failed.
Source:

<html><head><script src="resources/helper.js"></script><style>iframe { width: 100%; height: 100%; }</style>
</head><body><iframe src="resources/test/index.html?manipulation"></iframe>
</body></html>
Content-Type: text/plain

#EOF
#EOF
#EOF
LEAK: 76584 WebCoreNode
LEAK: 26 CachedResource

real    0m35.541s
user    0m35.346s
sys     0m0.048s


But if I marked it as slow in test_expectations.txt, it still fails, because it seems SLOW directive is only for NRWT and not for DRT. :(
Comment 3 Csaba Osztrogonác 2012-05-02 06:37:56 PDT
cc NRWT guys, and Adam as the author of the test.
Comment 4 Eric Seidel (no email) 2012-05-02 10:58:29 PDT
test_expectations has a "SLOW" designation, but we may need to break up the test.
Comment 5 Csaba Osztrogonác 2012-05-02 12:39:12 PDT
(In reply to comment #4)
> test_expectations has a "SLOW" designation, but we may need to break up the test.

That's what I mentioned. SLOW only works in NRWT side, but it seems that
NRWT doesn't pass timeout to the DRT and DRT exits early with notifydone
timeout after 30 secs independetly of SLOW directive in test_expectations.txt
Comment 6 Dirk Pranke 2012-05-02 14:04:21 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > test_expectations has a "SLOW" designation, but we may need to break up the test.
> 
> That's what I mentioned. SLOW only works in NRWT side, but it seems that
> NRWT doesn't pass timeout to the DRT and DRT exits early with notifydone
> timeout after 30 secs independetly of SLOW directive in test_expectations.txt

That's a problem, obviously. Either DRT needs to have no timeout or we need to pass a timeout to it that it honors.
Comment 7 Csaba Osztrogonác 2012-07-11 05:24:41 PDT
I have a workaround for this bug if the given DRT supports --timeout option.
Now only Qt port do it ... but it is buggy a little bit, but will be fixed
soon: https://bugs.webkit.org/show_bug.cgi?id=90966

You have to pass the following arguments to NRWT:
--additional-drt-flag=--timeout --additional-drt-flag=50000 --time-out-ms=50000

But unfortunately you have to modify the master.cfg to do it on the buildbot. :-/
Comment 8 Alexey Proskuryakov 2014-12-14 21:00:43 PST
Mac is affected too.

I'm going to mark the test as slow, and then we can see if something else needs to be done for other timeout guards.