The following testcase crashes on mozilla-central revision cb65ec85049e (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --ion-offthread-compile=off --baseline-eager): lfCodeBuffer = ` ArrayType = TypedObject.ArrayType; var StructType = TypedObject.StructType; float32 = TypedObject.float32; Point = new ArrayType(float32, 3); var Line = new StructType({ Point }); new ArrayType(Line, 3); `; loadFile(lfCodeBuffer); function loadFile(lfVarx) oomTest(function() { eval(lfVarx) }); Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0000000000a966a8 in js::CallJSNative (cx=0x7ffff6908800, native=0xbf16f0 <js::ArrayMetaTypeDescr::construct(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:238 #0 0x0000000000a966a8 in js::CallJSNative (cx=0x7ffff6908800, native=0xbf16f0 <js::ArrayMetaTypeDescr::construct(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:238 #1 0x0000000000a97933 in js::CallJSNativeConstructor (cx=0x7ffff6908800, native=0xbf16f0 <js::ArrayMetaTypeDescr::construct(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:268 #2 0x0000000000a94428 in InternalConstruct (cx=cx@entry=0x7ffff6908800, args=...) at js/src/vm/Interpreter.cpp:569 #3 0x0000000000a9466c in js::ConstructFromStack (cx=cx@entry=0x7ffff6908800, args=...) at js/src/vm/Interpreter.cpp:608 #4 0x0000000000618edf in js::jit::DoCallFallback (cx=0x7ffff6908800, frame=0x7fffffff9ed8, stub_=<optimized out>, argc=<optimized out>, vp=0x7fffffff9e68, res=...) at js/src/jit/BaselineIC.cpp:6095 #5 0x00007ffff7ff1a1f in ?? () [...] #31 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x7ffff6908800 140737330055168 rcx 0x7ffff6ca588d 140737333844109 rdx 0x0 0 rsi 0x7ffff6f7a9d0 140737336814032 rdi 0x7ffff6f791c0 140737336807872 rbp 0x7fffffff9a00 140737488329216 rsp 0x7fffffff99a0 140737488329120 r8 0x7ffff7fdf7c0 140737354004416 r9 0x6372732f736a2f6c 7165916604736876396 r10 0x7fffffff9760 140737488328544 r11 0x7ffff6c27ee0 140737333329632 r12 0x7fffffff9e68 140737488330344 r13 0x0 0 r14 0x7fffffff99c0 140737488329152 r15 0xbf16f0 12523248 rip 0xa966a8 <js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)+680> => 0xa966a8 <js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)+680>: movl $0xee,0x0 0xa966b3 <js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)+691>: callq 0x4abcb0 <abort()>

JSBugMon: Bisection requested, result: === Treeherder Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20160317020419" and the hash "7067e2812c2616061ce4328d0e97da4a3dd48387". The "bad" changeset has the timestamp "20160317022913" and the hash "83b0a247a47f1135a80454a9bd88c8f4c092a5d8". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7067e2812c2616061ce4328d0e97da4a3dd48387&tochange=83b0a247a47f1135a80454a9bd88c8f4c092a5d8

Not sure if this or the regression window is more relevant. Setting needinfo? from Jan as a start.

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2) > Not sure if this or the regression window is more relevant. Setting > needinfo? from Jan as a start. For pretty much all bugs with this signature, the regression window is not relevant. I'll take a look though.

TypedObject code was failing to check StringBuffer append() calls for OOM. I annotated these calls with MOZ_WARN_UNUSED_RESULT. That triggered many warnings in the JSON-generating code in jsopcode.cpp: we use unchecked append calls there and at the end we check cx->isExceptionPending(). I added OOM checks to all of these. Let me know if you think that's overkill; I can also go with the minimal TypedObject fix.

Comment on attachment 8743699 [details] [diff] [review] Patch Review of attachment 8743699 [details] [diff] [review]: ----------------------------------------------------------------- It's more verbose like this but it's simpler to see what's going on and more consistent with other code. r=me.

Try push uncovered another issue with this test: we need to call ReportOutOfMemory when typeDescrObjects.put() fails. I also noticed some unnecessary ReportOutOfMemory calls in TypedObject.cpp, because we're either appending to AutoValueVectors or StringBuffers that do their own OOM reporting.

Comment on attachment 8744628 [details] [diff] [review] More TypedObject OOM fixes Review of attachment 8744628 [details] [diff] [review]: ----------------------------------------------------------------- Ah, thank you for fixing that :)

https://hg.mozilla.org/integration/mozilla-inbound/rev/f53cce89320a https://hg.mozilla.org/integration/mozilla-inbound/rev/2fc9cdda3a7d

https://hg.mozilla.org/mozilla-central/rev/f53cce89320a https://hg.mozilla.org/mozilla-central/rev/2fc9cdda3a7d