1459258 - Crash [@ AutoAssertReportedException::~AutoAssertReportedException] or Assertion failure: cx_->isExceptionPending(), at js/src/frontend/BytecodeCompiler.cpp:588 with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 8994f35fe5fc (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe):

oomTest(function() {
  assertEq("\\u0130".toLocaleLowerCase([locale, "und"]), "i");
  assertEq("\\u0130".toLocaleLowerCase("trl"), "\\u0069\\u0307");
  assertThrowsInstanceOf(() => "A".toLocaleLowerCase([locale]), TypeError);
  for (let locale of [0, Math.PI, NaN, Infinity, true, false, Symbol()]) {
      "".toLocaleLowerCase(locale);
      assertEq("A".toLocaleLowerCase(locale), "a");
  }
  if (typeof reportCompare === "function") reportCompare(0, 0, "ok");
});


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x0000000000eb0fb5 in AutoAssertReportedException::~AutoAssertReportedException (this=0x7fffffffba60, __in_chrg=<optimized out>) at js/src/frontend/BytecodeCompiler.cpp:588
#0  0x0000000000eb0fb5 in AutoAssertReportedException::~AutoAssertReportedException (this=0x7fffffffba60, __in_chrg=<optimized out>) at js/src/frontend/BytecodeCompiler.cpp:588
#1  0x0000000000eac775 in js::frontend::CompileLazyFunction (cx=<optimized out>, lazy=..., lazy@entry=..., chars=<optimized out>, length=length@entry=448) at js/src/frontend/BytecodeCompiler.cpp:742
#2  0x0000000000b91290 in JSFunction::createScriptForLazilyInterpretedFunction (cx=<optimized out>, fun=...) at js/src/vm/JSFunction.cpp:1626
#3  0x00000000004779b8 in JSFunction::getOrCreateScript (cx=<optimized out>, fun=...) at js/src/vm/JSFunction.h:524
#4  0x00000000005a9551 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5f17000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:470
#5  0x00000000005a989d in InternalCall (cx=0x7ffff5f17000, args=...) at js/src/vm/Interpreter.cpp:516
#6  0x00000000005a9a20 in js::Call (cx=<optimized out>, fval=..., fval@entry=..., thisv=..., thisv@entry=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:535
#7  0x0000000000a48d21 in JS_CallFunction (cx=<optimized out>, obj=..., fun=..., fun@entry=..., args=..., rval=..., rval@entry=...) at js/src/jsapi.cpp:2948
#8  0x00000000008c6ce3 in OOMTest (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/TestingFunctions.cpp:1729
[...]
#23 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:9278
rax	0x0	0
rbx	0x7fffffffba60	140737488337504
rcx	0x7ffff6c282ad	140737333330605
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7fffffffba00	140737488337408
rsp	0x7fffffffb9e0	140737488337376
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4780	140737354024832
r10	0x58	88
r11	0x7ffff6b9e7a0	140737332766624
r12	0x7ffff5f17000	140737319628800
r13	0x7ffff5f17000	140737319628800
r14	0x7ffff480f000	140737295478784
r15	0x7fffffffbb30	140737488337712
rip	0xeb0fb5 <AutoAssertReportedException::~AutoAssertReportedException()+229>
=> 0xeb0fb5 <AutoAssertReportedException::~AutoAssertReportedException()+229>:	movl   $0x0,0x0
   0xeb0fc0 <AutoAssertReportedException::~AutoAssertReportedException()+240>:	ud2


This is happening quite frequently, marking as fuzzblocker.

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/ba3d6be51e34
user:        Tooru Fujisawa
date:        Sun Feb 26 14:02:36 2017 +0900
summary:     Bug 1342553 - Part 0.1: Use try-catch for IteratorClose in for-of. r=shu

This iteration took 256.685 seconds to run.

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Patch

OOM bug in BytecodeEmitter::makeAtomIndex.

The InlineMap used there has inline space for 24 entries, that makes it harder to find such bugs. I did an audit and found a similar bug elsewhere.

If I make it possible to simulate OOM also for inline entries, we would have found both issues when running jit-tests. I didn't add this to the patch because I don't know if we should do this (for Vector we don't simulate OOM for inline entries).

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Hard-to-reproduce variants also crash 64-bit debug shell [@ AutoAssertReportedException::~AutoAssertReportedException].

Thread 1 "js-dbg-64-linux" received signal SIGSEGV, Segmentation fault.
0x00005555560becc5 in AutoAssertReportedException::~AutoAssertReportedException (this=0x7fffffffa520, __in_chrg=<optimized out>) at /home/ubuntu/trees/mozilla-central/js/src/frontend/BytecodeCompiler.cpp:588
588	            MOZ_ASSERT(cx_->isExceptionPending());
#0  0x00005555560becc5 in AutoAssertReportedException::~AutoAssertReportedException (this=0x7fffffffa520, __in_chrg=<optimized out>) at /home/ubuntu/trees/mozilla-central/js/src/frontend/BytecodeCompiler.cpp:588
#1  0x00005555560ba6b5 in js::frontend::CompileLazyFunction (cx=<optimized out>, lazy=..., lazy@entry=..., chars=<optimized out>, length=length@entry=520) at /home/ubuntu/trees/mozilla-central/js/src/frontend/BytecodeCompiler.cpp:742
#2  0x0000555555da5060 in JSFunction::createScriptForLazilyInterpretedFunction (cx=<optimized out>, fun=...) at /home/ubuntu/trees/mozilla-central/js/src/vm/JSFunction.cpp:1626
#3  0x000055555568ed3c in JSFunction::getOrCreateScript (cx=<optimized out>, fun=...) at /home/ubuntu/trees/mozilla-central/js/src/vm/JSFunction.h:524
#4  0x00005555557bec11 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5d17000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /home/ubuntu/trees/mozilla-central/js/src/vm/Interpreter.cpp:470
#5  0x00005555557bef5d in InternalCall (cx=0x7ffff5d17000, args=...) at /home/ubuntu/trees/mozilla-central/js/src/vm/Interpreter.cpp:516
#6  0x00005555557bf0e0 in js::Call (cx=<optimized out>, fval=..., fval@entry=..., thisv=..., thisv@entry=..., args=..., rval=...) at /home/ubuntu/trees/mozilla-central/js/src/vm/Interpreter.cpp:535
/snip

Comment 6

[Jon Coppeard (:jonco)]

Comment on attachment 8973614 [details] [diff] [review]
Patch

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

Personally I'd say we should simulate OOM for inline entries in both cases, to help find stuff like this.

Patch looks good.

Comment 7

[Jan de Mooij [:jandem]]

Attachment: Simulate OOM for InlineMap inline entries

Comment 8

[Jon Coppeard (:jonco)]

Comment on attachment 8973947 [details] [diff] [review]
Simulate OOM for InlineMap inline entries

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

Great, thanks.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/40993c0bdc7a
Improve InlineMap OOM testing and fix some issues. r=jonco

Comment 10

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/40993c0bdc7a

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Is there a user impact here which warrants backport consideration?

Comment 12

[Jan de Mooij [:jandem]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #11)
> Is there a user impact here which warrants backport consideration?

No this is just a harmless OOM bug.