Summary: | REGRESSION(r163660-r163664): js/dom/stack-trace.html fails | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||||
Component: | JavaScriptCore | Assignee: | Mark Lam <mark.lam> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ggaren, mark.lam, webkit-bug-importer | ||||||
Priority: | P1 | Keywords: | InRadar | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Alexey Proskuryakov
2014-02-10 10:43:48 PST
Updated TestExpectations in <http://trac.webkit.org/r163798>. 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. I would change the test just to dump the top portion of the backtrace. (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. Created attachment 223754 [details]
fixed the test to be more resilient to stack usage changes.
Comment on attachment 223754 [details]
fixed the test to be more resilient to stack usage changes.
need to fix a tab.
Created attachment 223756 [details]
patch 2.
Thanks for the review. Landed in r163829: <http://trac.webkit.org/r163829>. |