Closed Bug 1261308 Opened 5 years ago Closed 5 years ago
_CRASH(Invalid PC offset for IC entry .) at js/src/jit/Baseline JIT .cpp:656 with OOM
The following testcase crashes on mozilla-central revision d5d53a3b4e50 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-debug, run with --fuzzing-safe --no-threads --ion-pgo=on --ion-eager --ion-offthread-compile=off --ion-check-range-analysis --ion-extra-checks): See attachment. Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x08265315 in js::jit::BaselineScript::icEntryFromPCOffset (this=0xf7a86080, pcOffset=0) at js/src/jit/BaselineJIT.cpp:656 #0 0x08265315 in js::jit::BaselineScript::icEntryFromPCOffset (this=0xf7a86080, pcOffset=0) at js/src/jit/BaselineJIT.cpp:656 #1 0x089fa8f9 in InitFromBailout (ionScript=<optimized out>, excInfo=<optimized out>, callPC=<synthetic pointer>, nextCallee=..., startFrameFormals=..., builder=..., invalidate=<optimized out>, iter=..., script=..., fun=..., callerPC=<optimized out>, cx=<optimized out>, caller=...) at js/src/jit/BaselineBailouts.cpp:1016 #2 js::jit::BailoutIonToBaseline (cx=cx@entry=0xf7a75020, activation=0xffffbb30, iter=..., invalidate=invalidate@entry=true, bailoutInfo=bailoutInfo@entry=0xffffb8a0, excInfo=excInfo@entry=0x0) at js/src/jit/BaselineBailouts.cpp:1564 #3 0x089fc57e in js::jit::InvalidationBailout (sp=0xffffb8a8, frameSizeOut=0xffffb8a4, bailoutInfo=0xffffb8a0) at js/src/jit/Bailouts.cpp:130 #4 0xf7fc898c in ?? () #5 0x08315749 in EnterIon (data=..., cx=0xf7a75020) at js/src/jit/Ion.cpp:2734 #6 js::jit::IonCannon (cx=cx@entry=0xf7a75020, state=...) at js/src/jit/Ion.cpp:2829 #7 0x08724a2f in js::RunScript (cx=cx@entry=0xf7a75020, state=...) at js/src/vm/Interpreter.cpp:406 #8 0x087276cd in js::ExecuteKernel (cx=cx@entry=0xf7a75020, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., evalInFrame=evalInFrame@entry=..., result=result@entry=0xffffc148) at js/src/vm/Interpreter.cpp:684 #9 0x08727992 in js::Execute (cx=cx@entry=0xf7a75020, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0xffffc148) at js/src/vm/Interpreter.cpp:717 #10 0x08559d1c in ExecuteScript (cx=cx@entry=0xf7a75020, scope=scope@entry=..., script=script@entry=..., rval=rval@entry=0xffffc148) at js/src/jsapi.cpp:4372 #11 0x0855da29 in JS_ExecuteScript (cx=0xf7a75020, scriptArg=scriptArg@entry=..., rval=rval@entry=...) at js/src/jsapi.cpp:4398 #12 0x080f4f8f in Evaluate (cx=0xf7a75020, argc=1, vp=0xffffc148) at js/src/shell/js.cpp:1514 #13 0xf7c74213 in ?? () eax 0x0 0 ebx 0x98cd7d0 160225232 ecx 0xf7e3a88c -136075124 edx 0x0 0 esi 0xf7a86110 -139960048 edi 0xffffffff -1 ebp 0xffffb448 4294947912 esp 0xffffb420 4294947872 eip 0x8265315 <js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)+229> => 0x8265315 <js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)+229>: movl $0x290,0x0 0x826531f <js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)+239>: call 0x8106890 <abort()> I tried to prettify the test but it reacts very unstable to further reduction and even removing line breaks lowered the chance of reproduction for me. As the test is right now, you also might have to run it multiple times to reproduce. I'm marking this as s-s because I don't know what's going on here and it crashes in a way that could be security-related.
I'm going to be conservative and mark it sec-high.
Jan, who do you think might be able to work on this? Thanks.
Tricky OOM bug. Baseline optimizes JSOP_GETGNAME undefined/NaN/Infinity, and we have to make sure Ion optimizes these cases as well. Here the global lexical scope had 'unknown properties', due to an OOM, so testGlobalLexicalBinding failed for 'undefined' and we ended up with an Ion IC.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Attachment #8746570 - Flags: review?(shu)
Comment on attachment 8746570 [details] [diff] [review] Patch Review of attachment 8746570 [details] [diff] [review]: ----------------------------------------------------------------- Oof, thanks for fixing this.
Attachment #8746570 - Flags: review?(shu) → review+
Jan, is this ready for sec-approval/landing?
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #7) > I bisected a possibly-related testcase that had a similar stack to bug > 1242812. The changes there can affect where we simulate OOM, but the underlying bug here is unrelated.
No longer blocks: 1242812
Guaranteed MOZ_CRASH, not s-s. https://hg.mozilla.org/integration/mozilla-inbound/rev/abfe6f9b1e082aff84afcf83337747386a2031ef
Since 48 is marked as affected, do you think this would be good to uplift to aurora? If not, we can wontfix for 48. Thanks!
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #11) > Since 48 is marked as affected, do you think this would be good to uplift to > aurora? If not, we can wontfix for 48. Thanks! I think this can wait - it's extremely unlikely to happen in the browser.
You need to log in before you can comment on or make changes to this bug.