Closed Bug 1305791 Opened 3 years ago Closed 3 years ago

Crash [@ jemalloc_crash] with OOM involving serialize


(Core :: JavaScript Engine, defect, critical)

Not set



Tracking Status
firefox49 --- unaffected
firefox50 --- unaffected
firefox51 --- fixed
firefox52 --- fixed


(Reporter: decoder, Assigned: kanru)


(Blocks 2 open bugs)


(Keywords: assertion, jsbugmon, testcase, Whiteboard: [jsbugmon:update])

Crash Data


(1 file)

The following testcase crashes on mozilla-central revision 66a77b9bfe5d (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --enable-optimize, run with --fuzzing-safe --thread-count=2 --baseline-eager --ion-offthread-compile=off):

var lfLogBuffer = `
  function testEq(b) {
    var a = deserialize(serialize(b));
function loadFile(lfVarx) {
  oomTest(function() {


 received signal SIGSEGV, Segmentation fault.
jemalloc_crash () at memory/mozjemalloc/jemalloc.c:1631
#0  jemalloc_crash () at memory/mozjemalloc/jemalloc.c:1631
#1  0x000000000048e0a3 in arena_dalloc (ptr=ptr@entry=0x7ffff3490000, offset=<optimized out>) at memory/mozjemalloc/jemalloc.c:4737
#2  0x000000000048e560 in free (ptr=0x7ffff3490000) at memory/mozjemalloc/jemalloc.c:6485
#3  0x0000000000b853bd in js_free (p=<optimized out>) at /srv/jenkins/jobs/mozilla-central-build-jsshell/workspace/arch/64/compiler/gcc/sanitizer/none/type/debug/dist/include/js/Utility.h:257
#4  js::TempAllocPolicy::free_ (this=0x7fffffff8de8, p=<optimized out>) at js/src/jsalloc.h:126
#5  mozilla::BufferList<js::TempAllocPolicy>::Clear (this=0x7fffffff8de8) at /srv/jenkins/jobs/mozilla-central-build-jsshell/workspace/arch/64/compiler/gcc/sanitizer/none/type/debug/dist/include/mozilla/BufferList.h:124
#6  mozilla::BufferList<js::TempAllocPolicy>::~BufferList (this=0x7fffffff8de8, __in_chrg=<optimized out>) at /srv/jenkins/jobs/mozilla-central-build-jsshell/workspace/arch/64/compiler/gcc/sanitizer/none/type/debug/dist/include/mozilla/BufferList.h:115
#7  js::SCOutput::~SCOutput (this=0x7fffffff8de0, __in_chrg=<optimized out>) at js/src/vm/StructuredClone.cpp:209
#8  JSStructuredCloneWriter::~JSStructuredCloneWriter (this=0x7fffffff8de0, __in_chrg=<optimized out>) at js/src/vm/StructuredClone.cpp:912
#9  0x0000000000b8ec2c in WriteStructuredClone (cx=cx@entry=0x7ffff695f000, v=..., bufp=bufp@entry=0x7fffffff9218, scope=scope@entry=JS::StructuredCloneScope::SameProcessSameThread, cb=cb@entry=0x0, cbClosure=cbClosure@entry=0x0, transferable=...) at js/src/vm/StructuredClone.cpp:492
#10 0x0000000000b8ee0a in JS_WriteStructuredClone (cx=cx@entry=0x7ffff695f000, value=..., bufp=bufp@entry=0x7fffffff9218, scope=JS::StructuredCloneScope::SameProcessSameThread, optionalCallbacks=optionalCallbacks@entry=0x0, closure=closure@entry=0x0, transferable=...) at js/src/vm/StructuredClone.cpp:2372
#11 0x0000000000b8ee8b in JSAutoStructuredCloneBuffer::write (this=this@entry=0x7fffffff9210, cx=cx@entry=0x7ffff695f000, value=..., transferable=..., optionalCallbacks=optionalCallbacks@entry=0x0, closure=closure@entry=0x0) at js/src/vm/StructuredClone.cpp:2537
#12 0x0000000000c90478 in Serialize (cx=cx@entry=0x7ffff695f000, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/TestingFunctions.cpp:2195
#13 0x0000000000af6719 in js::CallJSNative (cx=cx@entry=0x7ffff695f000, native=0xc90390 <Serialize(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:239
#14 0x0000000000ae6913 in js::InternalCallOrConstruct (cx=cx@entry=0x7ffff695f000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:458
#15 0x0000000000ae6c46 in InternalCall (cx=cx@entry=0x7ffff695f000, args=...) at js/src/vm/Interpreter.cpp:503
#16 0x0000000000ae6d6a in js::CallFromStack (cx=cx@entry=0x7ffff695f000, args=...) at js/src/vm/Interpreter.cpp:509
#17 0x0000000000e60af1 in js::jit::DoCallFallback (cx=0x7ffff695f000, frame=0x7fffffff97b8, stub_=<optimized out>, argc=<optimized out>, vp=0x7fffffff9750, res=...) at js/src/jit/BaselineIC.cpp:6010
#18 0x00007ffff7e3d08a in ?? ()
#63 0x00007fffffff9b90 in ?? ()
#64 0x00000000005c9bb2 in EnterBaseline (cx=0x7fffffff97b0, data=...) at js/src/jit/BaselineJIT.cpp:155
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
user:        Kan-Ru Chen
date:        Fri Apr 22 18:04:20 2016 +0800
summary:     Bug 1264642 - Part 4. Use BufferList to replace raw buffers in StructuredClone. r=baku r=billm r=jorendorff

This iteration took 241.094 seconds to run.
Kan-Ru, is bug 1264642 a likely regressor?
Blocks: 1264642
Flags: needinfo?(kchen)
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2)
> Kan-Ru, is bug 1264642 a likely regressor?

The signatures involved indeed are introduced by bug 1264642. It doesn't look like OOM though. I'll take a look.
Assignee: nobody → kchen
Flags: needinfo?(kchen)
Crash volume for signature 'jemalloc_crash':
 - nightly (version 52): 0 crashes from 2016-09-19.
 - aurora  (version 51): 0 crashes from 2016-09-19.
 - beta    (version 50): 535 crashes from 2016-09-20.
 - release (version 49): 0 crashes from 2016-09-05.
 - esr     (version 45): 0 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       0       0
 - aurora        0       0
 - beta        535       0
 - release       0       0
 - esr           0       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora
 - beta    #17       #44
 - release
 - esr
Comment on attachment 8796479 [details]
Bug 1305791 - Clear result.mSegments if MoveFallible failed.
Attachment #8796479 - Flags: review?(wmccloskey) → review+
Pushed by
Clear result.mSegments if MoveFallible failed. r=billm
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Comment on attachment 8796479 [details]
Bug 1305791 - Clear result.mSegments if MoveFallible failed.

Approval Request Comment
[Feature/regressing bug #]: bug 1264642
[User impact if declined]: Crash after structured clone OOM'd then recovered.
[Describe test coverage new/current, TreeHerder]: Landed on m-c, existing test coverage
[Risks and why]: Low. Just added a line to release resources properly.
[String/UUID change made/needed]: n/a
Attachment #8796479 - Flags: approval-mozilla-aurora?
Hi Kan-Ru & Marco,
From the crash report, there are more than 1000 crashes for 50.0b3, but there are no crashes for 51.0a2. Do we need to uplift this to aurora?
Flags: needinfo?(mcastelluccio)
Flags: needinfo?(kchen)
(In reply to Gerry Chang [:gchang] from comment #11)
> Hi Kan-Ru & Marco,
> From the crash report, there are more than 1000 crashes for 50.0b3, but
> there are no crashes for 51.0a2. Do we need to uplift this to aurora?

The crash report of this signature is incorrect as it's a very general signature. Actually this crash hasn't been noticed in the wild if you query jemalloc_crash && proto signature containing BufferList.

The probability of this happening is very rare and OOM in structured clone is already kind of hard to recover -- you will end up OOM crash in other places. But since structured clone is used increasingly by modern web via workers, I'd like to fix this newly introduced regression on Aurora.
Flags: needinfo?(kchen)
As Kan-Ru said, this signature is generic, this is why the bot got
confused. The crashes on 50 are not caused by the regression from
bug 1264642, which landed in 51.
Flags: needinfo?(mcastelluccio)
Comment on attachment 8796479 [details]
Bug 1305791 - Clear result.mSegments if MoveFallible failed.

Fix a crash. Take it in 51 aurora.
Attachment #8796479 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.