for (var y = 0; y < 999999; y++) { evalcx("print(x);function x(...x){}", newGlobal('')) } crashes js debug and opt shell on m-c changeset 3362afba690e without any CLI arguments at js_NewStringCopyN

I just verified that this seems to only occur with threadsafe js shells.

And I also verified that 32-bit and 64-bit Windows shells are affected, but Linux and Mac shells do not seem to be affected.

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

A faster testcase: for (var y = 0; y < 9999; y++) { evalcx("print(x);function x(...x){}", newGlobal('')) }

Even faster one: for (var y = 0; y < 999; y++) { evalcx("print(x);function x(...x){}", newGlobal('')) } autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 121521:79ebe1a5d8f4 user: Ms2ger date: Tue Feb 12 11:14:01 2013 +0100 summary: Bug 837176 - Simplify code flow in CheckSideEffects; r=jorendorff Ms2ger, is bug 837176 a likely regressor?

I would have hoped not... Jason?

(In reply to :Ms2ger from comment #6) > I would have hoped not... Jason? I'm not so sure anymore either. :-/ It is an unstable testcase. I changed the for loop to 99999: for (var y = 0; y < 99999; y++) { evalcx("print(x);function x(...x){}", newGlobal('')) } and have restarted autoBisect. More tomorrow.

I have managed to get a second possible regressor from the testcase in comment 7: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 121159:71f14579265f user: Benjamin Peterson date: Thu Feb 07 09:29:22 2013 -0500 summary: Bug 836515 - Allow source compression to run while executing the script. r=jorendorff jorendorff, you're probably the best person to evaluate the regression ranges.

It's more likely related to 71f14579265f. Unfortunately, I don't have Windows, so I probably won't be able to debug this.

Assuming sec-critical until otherwise shown. (there are some indications from the stack that it might just be a null deref, or not.. so let's have someone look at this first)

Adjusting flags and nominating for tracking on b2g, apparently bug 836515 landed on b2g as a performance improvement.

Comment on attachment 724238 [details] [diff] [review] tweak some defines This seems to fix the crash for me.

Comment on attachment 724238 [details] [diff] [review] tweak some defines Review of attachment 724238 [details] [diff] [review]: ----------------------------------------------------------------- This is fine, but if you think it's less error-prone to make all the compression *and* threading code conditional on having both USE_ZLIB and JS_THREADSAFE (thus supporting only two variants rather than four), please do that instead.

Definitely not security-sensitive.

Post-developer analysis, I guess this no longer needs to land on b2g, but this will be nice to have on the Aurora 21 branch though.

I don't think it needs to land on anything except central unless it blocks fuzzing. The patch is simple, but the bug doesn't afflict the browser.

(In reply to :Benjamin Peterson from comment #17) > I don't think it needs to land on anything except central unless it blocks > fuzzing. The patch is simple, but the bug doesn't afflict the browser. Yes, this blocks fuzzing on Windows (which is how I found this bug in the first place) on the Aurora 21 branch. I think they accept fuzzing blockers when requesting for landing approval.

I could make this trigger (via another unreliably large testcase) on Linux as well, but it was a lot more unreliable. I can somewhat confirm that the patch fixes this issue, too, on Linux.

Comment on attachment 724238 [details] [diff] [review] tweak some defines [Approval Request Comment] Blocks fuzzing on auroa. Very simple patch, which doesn't change browser.