Bug 128544 – REGRESSION(r163660-r163664): js/dom/stack-trace.html fails

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Alexey Proskuryakov]

http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK1%20(Tests)/r163792%20(2791)/js/dom/stack-trace-diff.txt

Looks like this started with either r163661 or r163664.

[Alexey Proskuryakov]

Updated TestExpectations in <http://trac.webkit.org/r163798>.

[Radar WebKit Bug Importer]

<rdar://problem/16027877>

[Mark Lam]

Note: this test does not fail for release builds.

The reason is because the issue lies in the debug build using a different amount of stack than a release build.  As a result, it encounters a stack overflow error at a different place.  I'll have to think about how we can make the test resilient to this kind of difference in stack usage rate.

[Geoffrey Garen]

I would change the test just to dump the top portion of the backtrace.

[Mark Lam]

(In reply to comment #4)
> I would change the test just to dump the top portion of the backtrace.

It already does.  However, the recursive parts (repeated in the stack trace) are:

    eval at [native code]                            <== Release build overflows here.
    selfRecursive3 at stack-trace.js:72:9
    at eval code                                        <== Debug build overflows here.

To fix this, I’m adding some facility to the test to check for a recursive pattern in the top part of the stack trace.  The test will pass the above if the top of the stack trace shows a repeated pattern that is expected no matter which line of the repeated pattern that the stack trace ends in.

[Mark Lam]

Created attachment 223754 [details]
fixed the test to be more resilient to stack usage changes.

[Mark Lam]

Comment on attachment 223754 [details]
fixed the test to be more resilient to stack usage changes.

need to fix a tab.

[Mark Lam]

Created attachment 223756 [details]
patch 2.

[Mark Lam]

Thanks for the review.  Landed in r163829: <http://trac.webkit.org/r163829>.