Closed Bug 1233178 Opened 9 years ago Closed 8 years ago

Assertion failure: !mEntered, at ../../dist/include/mozilla/Vector.h:444 with Debugger Coverage

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla47
Tracking Status
firefox46 --- wontfix
firefox47 --- fixed

People

(Reporter: decoder, Assigned: nbp)

References

Details

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

Attachments

(1 file)

The following testcase crashes on mozilla-central revision 749f9328dd76 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2):

gczeal(2)
g = newGlobal()
dbg = Debugger(g)
function loop() {
    for (;;) debugger
}
g.eval(loop.toSource())
dbg.onDebuggerStatement = function(f) {
    f.script.getOffsetsCoverage()
}
dbg.collectCoverageInfo = true
g.eval("loop")()



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000459016 in mozilla::Vector<js::PCCounts, 0ul, js::SystemAllocPolicy>::end (this=0x40a695) at ../../dist/include/mozilla/Vector.h:444
#0  0x0000000000459016 in mozilla::Vector<js::PCCounts, 0ul, js::SystemAllocPolicy>::end (this=0x40a695) at ../../dist/include/mozilla/Vector.h:444
#1  0x0000000000960150 in end (this=0x40a695) at js/src/jsscript.cpp:1490
#2  js::ScriptCounts::maybeGetThrowCounts (this=this@entry=0x7ffff460ce98, offset=offset@entry=24) at js/src/jsscript.cpp:1492
#3  0x00000000009ca1fc in DebuggerScript_getOffsetsCoverage (cx=0x7ffff6907400, argc=<optimized out>, vp=0x7ffff46711a8) at js/src/vm/Debugger.cpp:5708
#4  0x0000000000a7d572 in js::CallJSNative (cx=0x7ffff6907400, native=0x9c9ab0 <DebuggerScript_getOffsetsCoverage(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
#5  0x0000000000a75b27 in js::Invoke (cx=cx@entry=0x7ffff6907400, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:444
#6  0x0000000000a664ca in Interpret (cx=cx@entry=0x7ffff6907400, state=...) at js/src/vm/Interpreter.cpp:2766
#7  0x0000000000a758c7 in js::RunScript (cx=cx@entry=0x7ffff6907400, state=...) at js/src/vm/Interpreter.cpp:391
#8  0x0000000000a75bec in js::Invoke (cx=cx@entry=0x7ffff6907400, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:462
#9  0x0000000000a767b9 in js::Invoke (cx=cx@entry=0x7ffff6907400, thisv=..., fval=..., argc=argc@entry=1, argv=argv@entry=0x7fffffffb6a0, rval=..., rval@entry=...) at js/src/vm/Interpreter.cpp:496
#10 0x00000000009e037a in js::Debugger::fireDebuggerStatement (this=this@entry=0x7ffff6940800, cx=cx@entry=0x7ffff6907400, vp=..., vp@entry=...) at js/src/vm/Debugger.cpp:1240
#11 0x00000000009e0685 in operator() (dbg=0x7ffff6940800, __closure=<synthetic pointer>) at js/src/vm/Debugger.cpp:700
#12 dispatchHook<js::Debugger::slowPathOnDebuggerStatement(JSContext*, js::AbstractFramePtr)::__lambda3, js::Debugger::slowPathOnDebuggerStatement(JSContext*, js::AbstractFramePtr)::__lambda4> (fireHook=..., cx=0x7ffff6907400, hookIsEnabled=...) at js/src/vm/Debugger.cpp:1443
#13 js::Debugger::slowPathOnDebuggerStatement (cx=cx@entry=0x7ffff6907400, frame=...) at js/src/vm/Debugger.cpp:701
#14 0x00000000007e75e4 in onDebuggerStatement (frame=..., cx=0x7ffff6907400) at js/src/vm/Debugger-inl.h:50
#15 js::jit::OnDebuggerStatement (cx=0x7ffff6907400, frame=0x7fffffffbd28, pc=<optimized out>, mustReturn=0x7fffffffbcec) at js/src/jit/VMFunctions.cpp:985
#16 0x00007ffff7fe9f2f in ?? ()
[...]
#28 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff6907400	140737330050048
rcx	0x7ffff6ca53cd	140737333842893
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffffaa10	140737488333328
rsp	0x7fffffffaa10	140737488333328
r8	0x7ffff7fe0780	140737354008448
r9	0x6c697a6f6d2f6564	7811909647642617188
r10	0x7fffffffa7d0	140737488332752
r11	0x7ffff6c27960	140737333328224
r12	0xa	10
r13	0x7fffffffabc0	140737488333760
r14	0x18	24
r15	0x7fffffffabd0	140737488333776
rip	0x459016 <mozilla::Vector<js::PCCounts, 0ul, js::SystemAllocPolicy>::end() const+28>
=> 0x459016 <mozilla::Vector<js::PCCounts, 0ul, js::SystemAllocPolicy>::end() const+28>:	movl   $0x1bc,0x0
   0x459021 <mozilla::Vector<js::PCCounts, 0ul, js::SystemAllocPolicy>::end() const+39>:	callq  0x4a3db0 <abort()>
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:
changeset:   https://hg.mozilla.org/mozilla-central/rev/548a09b1a4e6
user:        Jon Coppeard
date:        Tue Nov 10 09:44:52 2015 +0000
summary:     Bug 1215063 - Add os.path.isAbsolute() and as.path.join() shell utilities r=sfink

This iteration took 272.367 seconds to run.
The bisection window in comment 1 probably isn't accurate, and I got the following result instead:

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/e5e97faa6d1d
user:        Nicolas B. Pierron
date:        Thu Oct 01 12:41:40 2015 +0200
summary:     Bug 1204554 part 3.4 - Ensure that scriptCountsMaps data are still alive until the destruction of compartments. r=terrence,bhackett

Nicolas, is bug 1204554 a likely regressor?
Blocks: 1204554
Flags: needinfo?(nicolas.b.pierron)
I will keep the ni? for the moment and investigate this issue later.
I do not yet see how the patch in comment 2 might be an issue, but at least the topic sounds related.
This issue is causing major amounts of reports. Marking as fuzzblocker.
Whiteboard: [jsbugmon:update] → [jsbugmon:update][fuzzblocker]
This is an automated crash issue comment:

Summary: Crash [@ js::ScriptCounts::maybeGetThrowCounts]
Build version: mozilla-central revision 9a358be6fa79
Build flags: --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --disable-debug
Runtime options: --fuzzing-safe --no-threads --disable-oom-functions

Testcase:

var g = newGlobal();
var dbg = Debugger(g);
var num = 20;
function loop(i) {
  for (n = 0; n < i; n++)
    debugger;
}
g.eval(loop.toSource());
dbg.onDebuggerStatement = function (f) {
  coverageInfo.push(f.callee.script.getOffsetsCoverage());
};
coverageInfo = [];
dbg.collectCoverageInfo = true;
g.eval("loop(" + num + ");");
schedulegc(100);
g.eval("loop(" + num + ");");


Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  js::ScriptCounts::maybeGetThrowCounts (this=this@entry=0xf7a60ae0, offset=offset@entry=54) at js/src/jsscript.cpp:1518
#1  0x08466a7f in DebuggerScript_getOffsetsCoverage (cx=0xf7a73040, argc=0, vp=0xffffa870) at js/src/vm/Debugger.cpp:5709
#2  0xf7fd2519 in ?? ()
#3  0xf64c86c0 in ?? ()
#4  0xf7fc9941 in ?? ()
#5  0x08154f15 in EnterBaseline (cx=cx@entry=0xf7a73040, data=...) at js/src/jit/BaselineJIT.cpp:135
#6  0x08157209 in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7a73040, state=...) at js/src/jit/BaselineJIT.cpp:173
#7  0x084b6195 in js::RunScript (cx=cx@entry=0xf7a73040, state=...) at js/src/vm/Interpreter.cpp:416
#8  0x084b63a3 in js::Invoke (cx=0xf7a73040, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:497
#9  0x084b7b42 in js::Invoke (cx=cx@entry=0xf7a73040, thisv=..., fval=..., argc=argc@entry=1, argv=argv@entry=0xffffad28, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:531
#10 0x0847d220 in js::Debugger::fireDebuggerStatement (this=this@entry=0xf7a97800, cx=0xf7a73040, vp=...) at js/src/vm/Debugger.cpp:1241
#11 0x0847d46e in operator() (dbg=0xf7a97800, __closure=<synthetic pointer>) at js/src/vm/Debugger.cpp:701
#12 dispatchHook<js::Debugger::slowPathOnDebuggerStatement(JSContext*, js::AbstractFramePtr)::__lambda3, js::Debugger::slowPathOnDebuggerStatement(JSContext*, js::AbstractFramePtr)::__lambda4> (fireHook=..., cx=<optimized out>, hookIsEnabled=...) at js/src/vm/Debugger.cpp:1444
#13 js::Debugger::slowPathOnDebuggerStatement (cx=cx@entry=0xf7a73040, frame=frame@entry=...) at js/src/vm/Debugger.cpp:702
#14 0x082e82a0 in onDebuggerStatement (frame=..., cx=0xf7a73040) at js/src/vm/Debugger-inl.h:50
#15 js::jit::OnDebuggerStatement (cx=0xf7a73040, frame=0xffffb050, pc=0xf630a2af "s\210", mustReturn=0xffffb030) at js/src/jit/VMFunctions.cpp:960
#16 0xf7fca302 in ?? ()
#17 0xf7fc9941 in ?? ()
#18 0x08154f15 in EnterBaseline (cx=cx@entry=0xf7a73040, data=...) at js/src/jit/BaselineJIT.cpp:135
[...]
#57 main (argc=6, argv=0xffffda94, envp=0xffffdab0) at js/src/shell/js.cpp:6974
eax	0x0	0
ebx	0x947f3dc	155710428
ecx	0xffffa750	-22704
edx	0xf7a7304c	-140038068
esi	0xe5e5e5e5	-437918235
edi	0x36	54
ebp	0xa5e5e5e5	2783307237
esp	0xffffa6cc	4294944460
eip	0x83fb28b <js::ScriptCounts::maybeGetThrowCounts(unsigned int) const+91>
=> 0x83fb28b <js::ScriptCounts::maybeGetThrowCounts(unsigned int) const+91>:	cmp    (%esi),%edi
   0x83fb28d <js::ScriptCounts::maybeGetThrowCounts(unsigned int) const+93>:	cmove  %esi,%eax
Assignee: nobody → nicolas.b.pierron
Flags: needinfo?(nicolas.b.pierron)
Comment on attachment 8709441 [details] [diff] [review]
Move ScriptCounts allocation outside the HashMap.

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

::: js/src/jsscript.cpp
@@ +1656,1 @@
>      compartment()->scriptCountsMap->remove(p);

Isn't this leaking the ScriptCounts entry pointer?
Attachment #8709441 - Flags: review?(bhackett1024) → review+
(In reply to Brian Hackett (:bhackett) from comment #8)
> ::: js/src/jsscript.cpp
> @@ +1656,1 @@
> >      compartment()->scriptCountsMap->remove(p);
> 
> Isn't this leaking the ScriptCounts entry pointer?

Good catch, adding a js_delete(p->value()) above should fix this.
https://hg.mozilla.org/mozilla-central/rev/42b7938ed64a
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Too late for assertion fixes in 46.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: