Terrence Cole wrote:
On 10/17/2012 10:01 PM, Nicholas Nethercote wrote:
Terrence and I have had problems with that one before. IIRC the test
has some bogosity about it, but I don't remember the details --
Terrence, do you?
I'll just echo what Nicolas said: anything that changes the interpreter
stack will randomly make this test explode in this way.
That test is not just some old dog to take out back and shoot. If it
barks, others will too. It's also testing things that are being
standardized in ES6.
We have a zero regression policy, project-wide (with short waivers
clearing orange by patching forward instead of backing out. For
SpiderMonkey we need either to fix a regression or remove a test that
was counting on a bug or misfeature that's not being standardized.
So in this case, we need a fix -- is there a bug on file?
That said, I
also hit this a bunch when implementing the StoreBuffer and that code
explicitly goes nowhere near the stack. I vaguely remember that someone
looked into it and found their compiler randomly deciding to give
js::Interpret a bogusly humongous frame.
These bugs come up from time to time. I just noticed
https://bugzilla.mozilla.org/show_bug.cgi?id=799494
still open.
I was /really/ hoping that unraveling the threaded interpreter would
make this problem go away permanently. That work landed over a week ago
in 109802:44079242ee9b. Brendan, what revision are you testing?
beich-10880:src brendaneich1$ hg tip
changeset: 110531:366998e4e1dc
tag: tip
user: Jonathan Kew <[email protected]>
date: Wed Oct 17 20:50:06 2012 +0100
summary: bug 794038 followup - add #include "nsIPresShell.h" to
nsChildView.mm to avoid relying on fragile indirect inclusion. rs=Ms2ger
/be
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
