Closed Bug 1262395 Opened 8 years ago Closed 8 years ago

Crash [@ readBarrier] with Debugger

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1266434
Tracking Status
firefox48 --- fixed

People

(Reporter: decoder, Assigned: jimb)

Details

(Keywords: crash, regression, testcase, Whiteboard: [jsbugmon:])

Crash Data

The following testcase crashes on mozilla-central revision 3930bfe289c8 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-debug, run with --fuzzing-safe --no-threads --baseline-eager):

for (var egc=8; egc < 10; ++egc) {
  g = newGlobal();
  dbg = Debugger(g);
  let m = parseModule(`
    gczeal(2,egc);
    g = newGlobal();
    g.evaluate("function f(){}");
    var w = dbg.addDebuggee(g);
    s = dbg.findScripts();
  `);
  m.declarationInstantiation();
  try {
    m.evaluation();
  } catch(exc1) {}
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
readBarrier (obj=0xe5e5e5e5e5e5e5e5) at js/src/jsobj.h:623
#0  readBarrier (obj=0xe5e5e5e5e5e5e5e5) at js/src/jsobj.h:623
#1  js::InternalBarrierMethods<js::GlobalObject*>::readBarrier (v=0xe5e5e5e5e5e5e5e5) at js/src/gc/Barrier.h:261
#2  0x000000000080e658 in read (this=0x7ffff6936d98) at js/src/gc/Barrier.h:555
#3  get (this=0x7ffff6936d98) at js/src/gc/Barrier.h:610
#4  operator-> (this=0x7ffff6936d98) at js/src/gc/Barrier.h:624
#5  js::Debugger::ScriptQuery::matchAllDebuggeeGlobals (this=this@entry=0x7fffffffbd50) at js/src/vm/Debugger.cpp:4001
#6  0x00000000007fecf6 in omittedQuery (this=0x7fffffffbd50) at js/src/vm/Debugger.cpp:3839
#7  js::Debugger::findScripts (cx=0x7ffff6907800, argc=<optimized out>, vp=<optimized out>) at js/src/vm/Debugger.cpp:4153
#8  0x000000000086e7a1 in CallJSNative (args=..., native=0x7fe840 <js::Debugger::findScripts(JSContext*, unsigned int, JS::Value*)>, cx=0x7ffff6907800) at js/src/jscntxtinlines.h:235
#9  js::Invoke (cx=cx@entry=0x7ffff6907800, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:476
#10 0x000000000053f666 in js::jit::DoCallFallback (cx=0x7ffff6907800, frame=0x7fffffffc338, stub_=0x7ffff52986d0, argc=0, vp=0x7fffffffc2e8, res=...) at js/src/jit/BaselineIC.cpp:6113
#11 0x00007ffff7ff0d54 in ?? ()
[...]
#21 0x0000000000000000 in ?? ()
rax	0xe5e5e5e5e5efffe8	-1880844493789331480
rbx	0xe5e5e5e5e5e5e5e5	-1880844493789993499
rcx	0x5	5
rdx	0x1	1
rsi	0x1	1
rdi	0xe5e5e5e5e5e5e5e5	-1880844493789993499
rbp	0xe5e5e5e5e5e00000	16565899579919171584
rsp	0x7fffffffbc90	140737488338064
r8	0x1	1
r9	0x7ffff6907840	140737330051136
r10	0x20	32
r11	0x1	1
r12	0x7fffffffbd50	140737488338256
r13	0x7ffff694b800	140737330329600
r14	0x7ffff6937c00	140737330248704
r15	0x0	0
rip	0x5ed3d3 <js::InternalBarrierMethods<js::GlobalObject*>::readBarrier(js::GlobalObject*)+35>
=> 0x5ed3d3 <js::InternalBarrierMethods<js::GlobalObject*>::readBarrier(js::GlobalObject*)+35>:	testb  $0x1,(%rax)
   0x5ed3d6 <js::InternalBarrierMethods<js::GlobalObject*>::readBarrier(js::GlobalObject*)+38>:	je     0x5ed3e8 <js::InternalBarrierMethods<js::GlobalObject*>::readBarrier(js::GlobalObject*)+56>


This only reproduced in an optimized build for me, no crash or assert in a debug build. It might be that another gczeal setting works there.
Whole log of jemalloc freed poison values in here, before we even get to Debugger frames...
Flags: needinfo?(jimb)
I can get a crash from this test case with a DEBUG build:

$ obj~/js/src/js --no-threads --baseline-eager ~/moz/crash3.js 
Assertion failure: generation == table_->generation(), at /home/jimb/moz/dbg/js/src/debug~/dist/include/js/HashTable.h:955
Segmentation fault (core dumped)
$ hg id
06678484909c central
$
Assignee: nobody → jimb
Flags: needinfo?(jimb)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:bisect]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Whiteboard: [jsbugmon:bisect] → [jsbugmon:]
So, from far away, here's what it looks like happened:

We got the WeakGlobalObjectSet::Range in matchAllDebuggeeGlobals. During one of the loop iterations, delazifying scripts as part of addCompartment() gc'd, which rekeyed the HashTable, and our range became stale and we went boom.

But: it doesn't repro anymore, since bug 1266434, which removed the code that could GC from addCompartment.

Jim, does this sound plausible, and does it seem like bug 1266434 is a viable fix?
Flags: needinfo?(jimb)
That seems plausible. I can't reproduce it any more, either.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(jimb)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.