1123661 - Assertion failure: entry.isJs(), at vm/SPSProfiler.cpp:365 or Crash [@ MarkInternal<JSAtom>]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

function printStatus (msg) {
  var lines = msg.split ("\n");
  for (var i=0; i < lines.length; i++)
    unescape (lines[i]);
}
function toPrinted(value) {
  value = String(value);
  value = value.replace(/\\n/g, 'NL').replace(/\n/g, 'NL')
}
function reportCompare (expected, actual) {
  toPrinted(expected) + toPrinted(actual) + "";
}
evaluate("gczeal(14)", { noScriptRval : true, compileAndGo : true });
enableSPSProfiling();
test();
function test() {
  printStatus ('');
  reportCompare(false, '');
  reportCompare(false, '');
  test() = 17;
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
MarkInternal<JSAtom> (trc=0x16c6058, thingp=0x16e2308) at js/src/gc/Marking.cpp:276
276	        if (IsInsideNursery(thing))
#0  MarkInternal<JSAtom> (trc=0x16c6058, thingp=0x16e2308) at js/src/gc/Marking.cpp:276
#1  0x00000000007bdacd in JSScript::markChildren (this=0x7ffff562e510, trc=0x16c6058) at js/src/jsscript.cpp:3402
#2  0x00000000004d1fc3 in MarkChildren (trc=0x16c6058, script=0x7ffff562e510) at js/src/gc/Marking.cpp:1356
#3  PushMarkStack (thing=0x7ffff562e510, gcmarker=0x16c6058) at js/src/gc/Marking.cpp:1101
#4  MarkInternal<JSScript> (trc=0x16c6058, thingp=<optimized out>) at js/src/gc/Marking.cpp:294
#5  0x000000000073b830 in trace (trc=0x16c6058, this=(JSFunction * const) 0x7ffff562d880 [object Function "ArrayStaticReduce"]) at js/src/jsfun.cpp:773
#6  fun_trace (trc=0x16c6058, obj=(JSObject *) 0x7ffff562d880 [object Function "ArrayStaticReduce"]) at js/src/jsfun.cpp:786
#7  0x000000000050dfd7 in js::GCMarker::processMarkStackTop (this=0x16c6058, budget=...) at js/src/gc/Marking.cpp:1831
#8  0x00000000004e6d8d in js::GCMarker::drainMarkStack (this=0x16c6058, budget=...) at js/src/gc/Marking.cpp:1894
#9  0x0000000000774636 in drainMarkStack (phase=js::gcstats::PHASE_MARK, sliceBudget=..., this=0x16be458) at js/src/jsgc.cpp:5225
#10 js::gc::GCRuntime::incrementalCollectSlice (this=0x16be458, budget=..., reason=<optimized out>) at js/src/jsgc.cpp:5893
#11 0x000000000077571e in js::gc::GCRuntime::gcCycle (this=0x16be458, incremental=false, budget=..., reason=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:6113
#12 0x0000000000775d14 in js::gc::GCRuntime::collect (this=0x16be458, incremental=false, budget=..., reason=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:6238
#13 0x0000000000777698 in gc (reason=JS::gcreason::DEBUG_GC, gckind=GC_SHRINK, this=0x16be458) at js/src/jsgc.cpp:6299
#14 js::gc::GCRuntime::runDebugGC (this=0x16be458) at js/src/jsgc.cpp:6687
#15 0x00000000008bbf58 in js::gc::CheckAllocatorState<(js::AllowGC)1> (cx=<optimized out>, kind=<optimized out>) at js/src/jsgcinlines.h:447
#16 0x0000000000911949 in CheckAllocatorState<(js::AllowGC)1> (cx=0x16e2cb0, kind=<optimized out>) at js/src/jsgcinlines.h:419
#17 AllocateNonObject<JSString, (js::AllowGC)1> (cx=0x16e2cb0) at js/src/jsgcinlines.h:538
#18 NewGCString<(js::AllowGC)1> (cx=0x16e2cb0) at js/src/jsgcinlines.h:627
#19 new_<(js::AllowGC)1> (cx=0x16e2cb0) at js/src/vm/String-inl.h:266
#20 AllocateInlineString<(js::AllowGC)1, unsigned char> (chars=<synthetic pointer>, len=<optimized out>, cx=0x16e2cb0) at js/src/vm/String-inl.h:31
#21 NewInlineString<(js::AllowGC)1, unsigned char> (chars=..., cx=0x16e2cb0) at js/src/vm/String-inl.h:57
#22 js::NewStringCopyNDontDeflate<(js::AllowGC)1, unsigned char> (cx=0x16e2cb0, s=0x7fffffffc700 "NaN", n=3) at js/src/vm/String.cpp:1011
#23 0x00000000007ab743 in NewStringCopyN<(js::AllowGC)1> (n=<optimized out>, s=0x7fffffffc700 "NaN", cx=0x16e2cb0) at js/src/vm/String.h:1140
#24 NewStringCopyZ<(js::AllowGC)1> (s=0x7fffffffc700 "NaN", cx=0x16e2cb0) at js/src/vm/String.h:1160
#25 js_NumberToStringWithBase<(js::AllowGC)1> (cx=0x16e2cb0, d=<optimized out>, base=10) at js/src/jsnum.cpp:1313
#26 0x00000000008213c3 in js::ToStringSlow<(js::AllowGC)1> (cx=0x16e2cb0, arg=...) at js/src/jsstr.cpp:4186
#27 0x0000000000881fac in ToString<(js::AllowGC)1> (v=..., cx=0x16e2cb0) at js/src/jsstr.h:152
#28 AddOperation (res=JSVAL_VOID, rhs=$jsval(""), lhs=$jsval(nan(0x8000000000000)), cx=0x16e2cb0) at js/src/vm/Interpreter.cpp:1245
#29 js::AddValues (cx=0x16e2cb0, lhs=$jsval(nan(0x8000000000000)), rhs=$jsval(""), res=JSVAL_VOID) at js/src/vm/Interpreter.cpp:3874
#30 0x00000000005cb956 in js::jit::DoBinaryArithFallback (cx=0x16e2cb0, frame=0x7fffffffcb28, stub_=0x16f07f0, lhs=$jsval(nan(0x8000000000000)), rhs=$jsval(""), ret=...) at js/src/jit/BaselineIC.cpp:2416
#31 0x00007ffff55b636a in ?? ()
#32 0x0000000000000202 in ?? ()
#33 0x00007fffffffcad0 in ?? ()
#34 0xfff9000000000000 in ?? ()
#35 0x00000000016b26a0 in js::jit::DoToNumberFallbackInfo ()
[...]
#52 0x0000000000000000 in ?? ()
rax	0x7ff7f56fffe8	140702951407592
rbx	0x16c6058	23879768
rcx	0x5ca2	23714
rdx	0xaeae68	11447912
rsi	0x16e2308	23995144
rdi	0x7ff7f561de80	140702950481536
rbp	0x16c6058	23879768
rsp	0x7fffffffc270	140737488339568
r8	0x400000200	17179869696
r9	0x16e22f8	23995128
r10	0x101	257
r11	0x1	1
r12	0x2	2
r13	0x7ffff5621240	140737310233152
r14	0x1	1
r15	0x7fffffffffff	140737488355327
rip	0x4d6e3c <MarkInternal<JSAtom>(JSTracer*, JSAtom**)+76>
=> 0x4d6e3c <MarkInternal<JSAtom>(JSTracer*, JSAtom**)+76>:	testb  $0x1,(%rax)
   0x4d6e3f <MarkInternal<JSAtom>(JSTracer*, JSAtom**)+79>:	jne    0x4d6e21 <MarkInternal<JSAtom>(JSTracer*, JSAtom**)+49


Marking s-s because this is a GC crash.

Comment 1

[Daniel Veditz [:dveditz]]

There's nothing obvious about profiling on the stack so rating this sec-high as a normal GC bug in case turning on profiling just happens to be a reliable way to expose the problem rather than the ONLY way to expose the problem. If it turns out to be profiling only then it would be sec-moderate.

Comment 2

[Christian Holler (:decoder)]

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/70a8168c7d24
user:        Kannan Vijayan
date:        Thu Jan 15 20:11:21 2015 -0500
summary:     Bug 1057082 - 3/7 - Modify jits to use lastProfilingFrame and lastProfilingCallSite fields. r=jandem

This iteration took 270.493 seconds to run.

Comment 3

[Andrew McCreight [:mccr8]]

ni? djvj for the regression identified in comment 2

Comment 4

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 2cb22c058add).

Comment 5

[Kannan Vijayan [:djvj]]

This is most likely coincidental on the patch.  My patches didn't really modify any gc-related behaviour.  I'll keep watching this, but I think it's caused by some other issue.  Can we bisect the change that caused to not reproduce?  If it's a gc-related bugfix, then this bug may be a duplicate of whatever bug that patch fixed.

Comment 6

[Andrew McCreight [:mccr8]]

Maybe this will work...

Comment 7

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/9ddd307bb5d1
user:        Tooru Fujisawa
date:        Tue Feb 10 02:04:30 2015 +0900
summary:     Bug 1120169 - Implement RegExp.prototype.{global, ignoreCase, multiline, source, sticky, unicode}. r=till

This iteration took 146.888 seconds to run.

Comment 8

[Al Billings [:abillings - ex-MoCo]]

Christian, what do we want to do here since this doesn't reproduce anymore?

Comment 9

[Christian Holler (:decoder)]

Bisecting the fix, but it's most likely fixed by the other bug on file with the same assertion.

Comment 10

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/9ddd307bb5d1
user:        Tooru Fujisawa
date:        Tue Feb 10 02:04:30 2015 +0900
summary:     Bug 1120169 - Implement RegExp.prototype.{global, ignoreCase, multiline, source, sticky, unicode}. r=till

This iteration took 2.281 seconds to run.

Comment 11

[Christian Holler (:decoder)]

That fix bisection doesn't sound right, maybe the bug is intermittent now. I'm putting a needinfo on djvj because it might be that this is the same as bug 1134515 and he's working on that right now.

Comment 12

[Kannan Vijayan [:djvj]]

I don't think this is the same bug as what I fixed in 1134515.  I suspect it has little to do with profiling at all, and just happens to be reasonably fragile and get "broken" and "fixed" by various random things.  Bug should be left open, but investigated independently of profiler development.

Comment 13

[Al Billings [:abillings - ex-MoCo]]

Has this issue occurred since March?

Comment 14

[Christian Holler (:decoder)]

No, I haven't seen this since March.

Comment 15

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Kannan Vijayan [:djvj] from comment #12)
> I don't think this is the same bug as what I fixed in 1134515.  I suspect it
> has little to do with profiling at all, and just happens to be reasonably
> fragile and get "broken" and "fixed" by various random things.  Bug should
> be left open, but investigated independently of profiler development.

Setting needinfo? from Jan as a fallback - :djvj might be busy with other projects now.

Comment 16

[Jan de Mooij [:jandem]]

I bisected this in a debug build (with --no-threads shell flag), to find out when this was fixed:

The first good revision is:
changeset:   233297:2d5eaa85e9da
user:        Kannan Vijayan <[e-mail]>
date:        Thu Mar 12 12:13:16 2015 -0400
summary:     Bug 1134515 - Ensure SPSBaselineOSRMarker checks pseudostack size properly. r=shu

That makes sense; bug 1134515 has exactly the same assertion failure.

Comment 17

[Jan de Mooij [:jandem]]

(FWIW, personally I'd mark this as DUPLICATE of bug 1134515 but Gary seems to prefer FIXED so I went with that...)

Comment 18

[Fuzzing Team]

JSBugMon: This bug has been automatically verified fixed.

Comment 19

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Jan de Mooij [:jandem] from comment #17)
> (FWIW, personally I'd mark this as DUPLICATE of bug 1134515 but Gary seems
> to prefer FIXED so I went with that...)

Yeah, if the fix is known, we go with FIXED. JSBugMon also verifies some FIXED security bugs automatically.

Comment 20

[Daniel Veditz [:dveditz]]

If this was fixed by bug 1134515 then ESR 38 should be fixed as well.