[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





--- Comment #8 from Mark Lam <mark.lam at apple.com>  2012-10-24 09:47:08 PST ---
Adding some instrumentation to inspect how much stack is available at the time the stack overflows are detected, and correlating that with whether we last saw xhr.onreadstatechange() with readyState 1 or readyState 4, I confirmed that the only determining factor as to whether whether the test produces 1 StackOverflowError or 2 is based on whether we run out of stack with readyState 1 or readyState 2.

The reason that this test did not seem flaky before 99872 is because previously, we did not do stack checks based on a measurement of available stack size, but instead estimated it based on depth of reentry into the interpreter.  With reentry depth, stack usage can differ between builds and platforms, but we will still be guaranteed the same number of interpreter/VM reentries and hence guarantee that we declare a stack overflow at one of the readyState 1 or readyState 4 point, and baseline the expected result accordingly.  This gives the illusion that the test is stable independent of stack usage. 

In summary, this means that the change set in 99872 only exposed a latent flakiness that was in the test to begin with.

Can we stabilize the test?
===============
No.  This is because the stack overflow is handled at the native level in WebCore.  The test (in JS) is not even aware that a stack overflow error has occurred.  Also, the test (in JS) has no way to determine how much native stack is available, nor how much stack usage per VM reentry is needed to ensure that we only see 1 StackOverflowError.  Hence, we will have to expect that the test will remain flaky.

Is this test still valid?
============
Yes.  The goal of the test is to verify that the test did not crash.  I believe leaving the test marked as flaky should serve this purpose adequately, and we only need to pay attention to it when it crashes.

Hence, I think there is nothing to fix here.

I will take a look at Csaba's other test failure before closing this as WONT FIX.

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