Closed Bug 1261308 Opened 5 years ago Closed 5 years ago

Hit MOZ_CRASH(Invalid PC offset for IC entry.) at js/src/jit/BaselineJIT.cpp:656 with OOM


(Core :: JavaScript Engine: JIT, defect)

Not set



Tracking Status
firefox48 --- wontfix
firefox49 --- fixed


(Reporter: decoder, Assigned: jandem)


(Blocks 1 open bug)


(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:ignore])


(2 files)

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.


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.
Attached file Testcase
Group: core-security → javascript-core-security
I'm going to be conservative and mark it sec-high.
Component: JavaScript Engine → JavaScript Engine: JIT
Keywords: sec-high
Jan, who do you think might be able to work on this? Thanks.
Flags: needinfo?(jdemooij)
Attached patch PatchSplinter Review
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
Flags: needinfo?(jdemooij)
Attachment #8746570 - Flags: review?(shu)
Comment on attachment 8746570 [details] [diff] [review]

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?
Flags: needinfo?(jdemooij)
I bisected a possibly-related testcase that had a similar stack to bug 1242812.
Blocks: 1242812
(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.
Group: javascript-core-security
Flags: needinfo?(jdemooij)
Keywords: sec-high
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
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!
Flags: needinfo?(jdemooij)
(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.
Flags: needinfo?(jdemooij)
You need to log in before you can comment on or make changes to this bug.