The following testcase asserts on mozilla-central revision 1d0496e30feb (x86 ARM simulator build, run with --fuzzing-safe --ion-eager --ion-check-range-analysis): loadFile("assertEq(Math.pow(-Infinity, -0.5), 0);"); loadFile(""); function loadFile(lfVarx) { function newFunc(x) { new Function(x)(); }; newFunc(lfVarx, unescape("notused")); }

Jan mentioned that this looks like another ARM assembler buffer issue, which could potentially be s-s, so filing as security bug for now until investigated.

I'm pretty sure this is caused by the ARM assembler bail/fail_bail mechanism. Then we |return false;| from bailoutFrom and we assert because the Label is unused. Doug, is this bail/fail_bail stuff going away with the assembler buffer rewrite? It's a very simple testcase, I hope we're not aborting JIT compilation all the time due to this..

(In reply to Jan de Mooij [:jandem] from comment #2) > I'm pretty sure this is caused by the ARM assembler bail/fail_bail > mechanism. Then we |return false;| from bailoutFrom and we assert because > the Label is unused. > > Doug, is this bail/fail_bail stuff going away with the assembler buffer > rewrite? Yes, it not longer has this bail out path. > It's a very simple testcase, I hope we're not aborting JIT > compilation all the time due to this.. Yes, this failure occurs after a constant pool packing failure. I have no statistics on how frequently this path is taken, but it has been a bigger problem testing asm.js code, and a bigger problem for the ARMv6 builds.

Is this actually a security issue? Or are we just bailing out?

(In reply to Andrew McCreight [:mccr8] from comment #4) > Is this actually a security issue? Or are we just bailing out? Bailing out is not a security issue, and it appears that the assertion can be ignored, so it does not appear to be a security issue. Although I have not actually explored what happens if the assertion is removed.

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 951e3a671279).

No action in 15 months.