1212278 - Assertion failure: aIndex < mLength, at ../../dist/include/mozilla/Vector.h:438 with OOM

Status: RESOLVED DUPLICATE of bug 1215058

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 727d765a5ed8 (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 --thread-count=2 --ion-extra-checks):

See attachment.


Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0871d7d7 in operator[] (aIndex=<optimized out>, this=0xf50bbbbc) at ../../dist/include/mozilla/Vector.h:438
#1  writeByteAt (byte=<optimized out>, pos=<optimized out>, this=0xf50bbbbc) at js/src/jit/CompactBuffer.h:128
#2  writeUnsignedAt (original=0, value=0, pos=40, this=0xf50bbbbc) at js/src/jit/CompactBuffer.h:141
#3  js::jit::SafepointWriter::writeNunboxParts (this=this@entry=0xf50bbbbc, safepoint=safepoint@entry=0xf4ed1f00) at js/src/jit/Safepoints.cpp:362
#4  0x0871d8d6 in js::jit::SafepointWriter::encode (this=this@entry=0xf50bbbbc, safepoint=0xf4ed1f00) at js/src/jit/Safepoints.cpp:379
#5  0x0871d9cd in js::jit::CodeGeneratorShared::encodeSafepoints (this=this@entry=0xf50bb000) at js/src/jit/shared/CodeGenerator-shared.cpp:632
#6  0x0861f4fa in js::jit::CodeGenerator::link (this=this@entry=0xf50bb000, cx=cx@entry=0xf7277020, constraints=0xf4ed0100) at js/src/jit/CodeGenerator.cpp:8003
#7  0x08621656 in LinkCodeGen (cx=cx@entry=0xf7277020, builder=builder@entry=0xf4ed0150, codegen=codegen@entry=0xf50bb000, scripts=scripts@entry=..., info=info@entry=0xffa53a40) at js/src/jit/Ion.cpp:555
#8  0x08621de5 in LinkBackgroundCodeGen (info=0xffa53a40, scripts=..., builder=0xf4ed0150, cx=0xf7277020) at js/src/jit/Ion.cpp:577
#9  js::jit::LazyLink (cx=cx@entry=0xf7277020, calleeScript=calleeScript@entry=...) at js/src/jit/Ion.cpp:603
#10 0x086221cc in js::jit::LazyLinkTopActivation (cx=0xf7277020) at js/src/jit/Ion.cpp:634
#11 0xf740e25f in ?? ()
#12 0xf50a8ed0 in ?? ()
#13 0xf740fcda in ?? ()
#14 0xf721f6c8 in ?? ()
#15 0xf7407c5c in ?? ()
#16 0x084e9785 in EnterBaseline (cx=0xf50a8ed0, cx@entry=0xf7277020, data=...) at js/src/jit/BaselineJIT.cpp:126
#17 0x08532381 in js::jit::EnterBaselineAtBranch (cx=0xf7277020, fp=0xf52b4028, pc=0xf72399c1 "\343\201C\b\377\377\377Z\231\230&\210\004\235)\210\bʘ5\210\t\230\001\220א\210\004\226\210\004\226\210\004\226\210\004\225\210\bʐ\210\bʐ\210\bϘ\002\234\v\210\003\230\016Ј\026\220Ј\027\220Ј \220Ј\027\220Ј?\220Ј\024\220Ј\030\230\027Ј,\230\031\210\004\314\b\225\210\002Έ\020\230&\210\004͈\020\230((\200") at js/src/jit/BaselineJIT.cpp:229
#18 0x083632c9 in Interpret (cx=cx@entry=0xf7277020, state=...) at js/src/vm/Interpreter.cpp:2120
#19 0x08366351 in js::RunScript (cx=cx@entry=0xf7277020, state=...) at js/src/vm/Interpreter.cpp:709
#20 0x0836c545 in js::ExecuteKernel (cx=cx@entry=0xf7277020, script=..., script@entry=..., scopeChainArg=..., thisv=..., newTargetValue=..., type=js::EXECUTE_GLOBAL, evalInFrame=evalInFrame@entry=..., result=result@entry=0x0) at js/src/vm/Interpreter.cpp:983
#21 0x0836c8af in js::Execute (cx=cx@entry=0xf7277020, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0x0) at js/src/vm/Interpreter.cpp:1018
#22 0x087fc62a in ExecuteScript (cx=cx@entry=0xf7277020, scope=..., script=script@entry=..., rval=rval@entry=0x0) at js/src/jsapi.cpp:4453
#23 0x087fc766 in JS_ExecuteScript (cx=cx@entry=0xf7277020, scriptArg=scriptArg@entry=...) at js/src/jsapi.cpp:4484
#24 0x0806b620 in RunFile (compileOnly=false, file=0xf72e99e0, filename=0xffa55ae4 "driver.js", cx=0xf7277020) at js/src/shell/js.cpp:468
#25 Process (cx=cx@entry=0xf7277020, filename=0xffa55ae4 "driver.js", forceTTY=forceTTY@entry=false) at js/src/shell/js.cpp:586
#26 0x080d0231 in ProcessArgs (op=0xffa548b0, cx=0xf7277020) at js/src/shell/js.cpp:5901
#27 Shell (envp=<optimized out>, op=0xffa548b0, cx=0xf7277020) at js/src/shell/js.cpp:6223
#28 main (argc=6, argv=0xffa54a04, envp=0xffa54a20) at js/src/shell/js.cpp:6579
eax	0x0	0
ebx	0x97a3434	159003700
ecx	0xf75c288c	-144955252
edx	0x0	0
esi	0xf50bbbbc	-183780420
edi	0x0	0
ebp	0xffa536d8	4289017560
esp	0xffa53680	4289017472
eip	0x871d7d7 <js::jit::SafepointWriter::writeNunboxParts(js::jit::LSafepoint*)+1287>
=> 0x871d7d7 <js::jit::SafepointWriter::writeNunboxParts(js::jit::LSafepoint*)+1287>:	movl   $0x1b6,0x0
   0x871d7e1 <js::jit::SafepointWriter::writeNunboxParts(js::jit::LSafepoint*)+1297>:	call   0x80f1660 <abort()>


The attached test doesn't seem to reproduce the issue for me anymore but nbp has already found the issue in our codebase. Since this is a range assertion being violated, I assume it's s-s.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Nicolas B. Pierron [:nbp]]

Attachment: Check for oom before writing back into the buffer.

Comment 3

[Fuzzing Team]

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

Comment 4

[Hannes Verschore [:h4writer]]

Comment on attachment 8670733 [details] [diff] [review]
Check for oom before writing back into the buffer.

Review of attachment 8670733 [details] [diff] [review]:
-----------------------------------------------------------------

https://dxr.mozilla.org/mozilla-central/source/js/src/jit/CompactBuffer.h#181
Can we assert here: MOZ_ASSERT(!oom());

https://dxr.mozilla.org/mozilla-central/source/js/src/jit/CompactBuffer.h#184
Can we assert here: MOZ_ASSERT(!oom());

r+ with raised issues addressed.

::: js/src/jit/CompactBuffer.h
@@ +120,4 @@
>      // Note: writeByte() takes uint32 to catch implicit casts with a runtime
>      // assert.
>      void writeByte(uint32_t byte) {
>          MOZ_ASSERT(byte <= 0xFF);

can you also add:
"if (oom())
     return;"
here?

I know it is not needed, but I think it is a wrong behavior to try adding more information to the buffer even after we failed already once. As a result putting inconsistent data into "buffer" and asking for even more memory. Lets just return.