[Webkit-unassigned] [Bug 100117] REGRESSION(r132143): It made fast/xmlhttprequest/xmlhttprequest-recursive-sync-event.html flakey

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=100117


Mark Lam <mark.lam at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|100109                      |




--- Comment #5 from Mark Lam <mark.lam at apple.com>  2012-10-23 22:03:40 PST ---
This test itself is intrinsically flaky to begin with.  The test failure has nothing to with bug 100109 nor 99872.  Will remove 100109 as a dependency as it is unrelated, but will leave 99872 because this latent issue was exposed when 99872 landed.    Here are the details:

This is what the test does:

function test()
{
    ...
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
        if (xhr.readyState == 4) {
            xhr.open("GET", "recurse.html", false);
            xhr.send(null);
        }
    };
    xhr.open("GET", "recurse.html", false);
    xhr.send(null);
    ...
}

Note that the XMLHttpRequest is a synchronous one.  Hence, the above code is set up as a means to achieve infinite recursion with the following pattern:

test()
   calls xhr.send() 
      which calls xhr.onreadstatechange() with readyState = 1
      and calls xhr.onreadstatechange() with readyState = 4
         which calls xhr.send()
            which calls xhr.onreadstatechange() with readyState = 1
            and calls xhr.onreadstatechange() with readyState = 4
               which calls xhr.send()
                  which calls xhr.onreadstatechange() with readyState = 1
                  and calls xhr.onreadstatechange() with readyState = 4
                     which calls xhr.send()
                        which ...
                        and ...
                           ...
                           which calls xhr.onreadstatechange() with readyState = 1  // case 1
                           and calls xhr.onreadstatechange() with readyState = 4 // case 2
                           ...

At some point, a stack overflow will be detected.  If the stack overflows during the execution right after case 1, the test won't get to call send() again.  So, a stack overflow gets thrown, and no more recursion take place.  In this case, the test will report only 1 StackOverflowError.

If the stack overflows during the execution right after case 2, the test would have just received a state change with readyState 4 and has just sent another request.  The invocation of case 2 causes a StackOverflowError to be thrown and is uncaught all the way out to the WebCore event dispatcher.  But the send() queues another event which causes the dispatcher to re-enter the interpreter again.  This in turn causes triggers a 2nd StackOverflowError.

I haven't isolated the exact root cause yet, but whether the test sees 1 or 2 StackOverflowErrors seem to depend on some race condition.  Here are 2 observations which supports that:
1. If I add/remove a printf to JSEventListener::handleEvent() (which is in the event dispatch code path), it can alter the result between the 2 outcomes.
2. A release build of DumpRenderTree that passes the test when run via run-webkit-test will fail the test if I run DumpRenderTree on the individual test case from the command line.

It doesn't look like the test failure has to do with the amount of stack space available, and hence is not really caused by 99872.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.