Assertion failure: cx->isExceptionPending(), at builtin/TestingFunctions.cpp:1158 with OOM

RESOLVED FIXED in Firefox 44

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: decoder, Assigned: jonco)

Tracking

(Blocks: 2 bugs, 4 keywords)

Trunk
mozilla44
x86_64
Linux
assertion, crash, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox44 fixed)

Details

(Whiteboard: [jsbugmon:update])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
The following testcase crashes on mozilla-central revision 4f4615ffec6a (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-extra-checks --ion-offthread-compile=off --ion-check-range-analysis). Actually I see multiple ones involving different functions that OOM:

oomTest(() => parseModule(10));

or this:

var lfcode = new Array();
oomTest((function(x) {
    assertEq(...Object);
}));


or this:

var lfcode = new Array();
oomTest(() => getBacktrace({}));


Not sure if these are distinct bugs not, but I can't seem to differentiate them by the stack, they all look like this:


Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000007d1703 in OOMTest (cx=0x7f7c6df06c00, argc=<optimized out>, vp=<optimized out>) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/builtin/TestingFunctions.cpp:1158
#1  0x00000000009e4412 in js::CallJSNative (cx=0x7f7c6df06c00, native=0x7d13a0 <OOMTest(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jscntxtinlines.h:235
#2  0x00000000009e0d70 in js::Invoke (cx=cx@entry=0x7f7c6df06c00, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/vm/Interpreter.cpp:784
#3  0x00000000009d229a in Interpret (cx=cx@entry=0x7f7c6df06c00, state=...) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/vm/Interpreter.cpp:3107
#4  0x00000000009e057b in js::RunScript (cx=cx@entry=0x7f7c6df06c00, state=...) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/vm/Interpreter.cpp:725
#5  0x00000000009e2f9c in js::ExecuteKernel (cx=cx@entry=0x7f7c6df06c00, script=..., script@entry=..., scopeChainArg=..., thisv=..., newTargetValue=..., type=<optimized out>, evalInFrame=..., evalInFrame@entry=..., result=result@entry=0x0) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/vm/Interpreter.cpp:1000
#6  0x00000000009e3409 in js::Execute (cx=cx@entry=0x7f7c6df06c00, script=script@entry=..., scopeChainArg=..., rval=0x0) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/vm/Interpreter.cpp:1035
#7  0x00000000008444e7 in Evaluate (cx=cx@entry=0x7f7c6df06c00, scope=..., staticScope=staticScope@entry=..., optionsArg=..., srcBuf=..., rval=..., rval@entry=...) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsapi.cpp:4693
#8  0x00000000008449b6 in JS::Evaluate (cx=cx@entry=0x7f7c6df06c00, options=..., bytes=<optimized out>, length=71, rval=..., rval@entry=...) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsapi.cpp:4747
#9  0x000000000085317e in Evaluate (rval=..., filename=<optimized out>, optionsArg=..., cx=0x7f7c6df06c00, cx@entry=0x7fff8971f5c0) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsapi.cpp:4764
#10 JS::Evaluate (cx=cx@entry=0x7f7c6df06c00, optionsArg=..., filename=<optimized out>, rval=..., rval@entry=...) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsapi.cpp:4802
#11 0x00000000004936d9 in LoadScript (cx=0x7f7c6df06c00, argc=<optimized out>, vp=0x7fff8971f8a8, scriptRelative=false) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/shell/js.cpp:839
#12 0x00007f7c6e10e4cd in ?? ()
#13 0x0000000000000073 in ?? ()
#14 0x00007fff8971f880 in ?? ()
#15 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x2	2
rcx	0x7f7c6e22a88d	140172400437389
rdx	0x0	0
rsi	0x7f7c6e4ff9d0	140172403407312
rdi	0x7f7c6e4fe1c0	140172403401152
rbp	0x7fff8971e8d0	140735499331792
rsp	0x7fff8971e7f0	140735499331568
r8	0x7f7c6f56f780	140172420642688
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7f7c6e4fbbe0	140172403391456
r11	0x0	0
r12	0x7fff8971e880	140735499331712
r13	0x3	3
r14	0x7f7c6df06c00	140172397145088
r15	0x1b4e01c	28631068
rip	0x7d1703 <OOMTest(JSContext*, unsigned int, JS::Value*)+867>
=> 0x7d1703 <OOMTest(JSContext*, unsigned int, JS::Value*)+867>:	movl   $0x486,0x0
   0x7d170e <OOMTest(JSContext*, unsigned int, JS::Value*)+878>:	callq  0x4a51c0 <abort()>

Updated

2 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]

Comment 1

2 years ago
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20151013053056" and the hash "8d9c20c241be7d7b3cfa90a3368a77db42172781".
The "bad" changeset has the timestamp "20151013054956" and the hash "d80f9d6921f8209ef01aa730be9a97ab727704d1".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8d9c20c241be7d7b3cfa90a3368a77db42172781&tochange=d80f9d6921f8209ef01aa730be9a97ab727704d1
(Assignee)

Comment 2

2 years ago
Yes, they are all different bugs with the same symptom - the operation fails due to OOM but we don't report the error.  The stack is the same due to it being checked in the same place in the oomTest() function.
(Assignee)

Comment 3

2 years ago
Created attachment 8675763 [details] [diff] [review]
bug1215363-various-ooms

Fix a couple of OOM handling bugs.

I had to change the sprintf-style functions in jsprf.cpp to crash when passed a bad format string so that we can assume that a nullptr return means out of memory.
Assignee: nobody → jcoppeard
Attachment #8675763 - Flags: review?(terrence)
Comment on attachment 8675763 [details] [diff] [review]
bug1215363-various-ooms

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

Nice!

::: js/src/jsprf.cpp
@@ +374,5 @@
>          while (c != 0) {
>              if (c > '9' || c < '0') {
>                  if (c == '$') {         // numbered argument case
>                      if (i > 0)
> +                        MOZ_CRASH("Bad format string");

\o/

I've always wondered if this error handling wasn't grossly unsafe and/or why we're not just crashing on bad paths here.
Attachment #8675763 - Flags: review?(terrence) → review+

Comment 5

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/6f1f7fc0f7cd

Comment 6

2 years ago
backoutbugherdermerge
https://hg.mozilla.org/mozilla-central/rev/6f1f7fc0f7cd
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox44: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in before you can comment on or make changes to this bug.