1125840 - Crash [@ ObjectType]

Status: RESOLVED DUPLICATE of bug 1125770

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

gczeal(14);
  for (var i = 0; i < 10; i) {
    var f = function() {
  }
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x000000000065c845 in ObjectType (obj=<optimized out>) at js/src/jsinferinlines.h:128
128	        return Type(uintptr_t(obj) | 1);
#0  0x000000000065c845 in ObjectType (obj=<optimized out>) at js/src/jsinferinlines.h:128
#1  GetValueType (val=...) at js/src/jsinferinlines.h:152
#2  GetValueType (val=...) at js/src/jit/IonBuilder.cpp:59
#3  GetMaybeUntrackedValueType (val=...) at js/src/jsinferinlines.h:166
#4  js::jit::NewBaselineFrameInspector (temp=0x170af20, frame=0x7fffffffdf08, info=0x170afa8) at js/src/jit/IonBuilder.cpp:71
#5  0x00000000005c71b5 in IonCompile (optimizationLevel=js::jit::Optimization_Normal, recompile=false, constructing=<optimized out>, osrPc=<optimized out>, baselineFrame=0x7fffffffdf08, script=0x7ffff565e128, cx=0x16e4d60) at js/src/jit/Ion.cpp:1778
#6  js::jit::Compile (cx=0x16e4d60, script=0x7ffff565e128, osrFrame=0x7fffffffdf08, osrPc=<optimized out>, constructing=<optimized out>, forceRecompile=<optimized out>) at js/src/jit/Ion.cpp:2001
#7  0x00000000005c7921 in js::jit::CanEnterAtBranch (cx=0x16e4d60, script=0x7ffff565e128, osrFrame=<optimized out>, pc=0x170ae97 "ず") at js/src/jit/Ion.cpp:2070
#8  0x00000000005c7c43 in EnsureCanEnterIon (jitcodePtr=<synthetic pointer>, pc=0x170ae97 "ず", script=0x7ffff565e128, frame=0x7fffffffdf08, cx=0x16e4d60, stub=<optimized out>) at js/src/jit/BaselineIC.cpp:763
#9  DoWarmUpCounterFallback (infoPtr=0x7fffffffdee0, frame=0x7fffffffdf08, stub=<optimized out>, cx=0x16e4d60) at js/src/jit/BaselineIC.cpp:927
#10 js::jit::DoWarmUpCounterFallback (cx=0x16e4d60, stub=<optimized out>, frame=0x7fffffffdf08, infoPtr=0x7fffffffdee0) at js/src/jit/BaselineIC.cpp:884
#11 0x00007ffff55b69b4 in ?? ()
#12 0x00007fffffffe270 in ?? ()
#13 0x00007fffffffdea8 in ?? ()
#14 0x00007fffffffe310 in ?? ()
#15 0x00000000016b6480 in InterpretResumeInfo ()
#16 0x00007ffff5650f10 in ?? ()
#17 0x00007ffff55bb006 in ?? ()
#18 0x0000000000000302 in ?? ()
#19 0x0000000001713078 in ?? ()
#20 0x00007fffffffdf08 in ?? ()
#21 0x00007fffffffdee0 in ?? ()
#22 0x0000000000000000 in ?? ()
rax	0x7ffff565a061	140737310466145
rbx	0x170b010	24162320
rcx	0x4949494949494949	5280832617179597129
rdx	0xfffc7ffff565a060	-985162596376480
rsi	0xfff80000ffffffff	-2251795518717953
rdi	0x170af20	24162080
rbp	0x7fffffffdf08	140737488346888
rsp	0x7fffffffdb50	140737488345936
r8	0x2	2
r9	0x0	0
r10	0xc1834801c7834819	-4502676029960927207
r11	0x1c6ee7501ee8301	128051825737630465
r12	0x170afa8	24162216
r13	0x170af20	24162080
r14	0x170aaf0	24161008
r15	0x170afa8	24162216
rip	0x65c845 <js::jit::NewBaselineFrameInspector(js::jit::TempAllocator*, js::jit::BaselineFrame*, js::jit::CompileInfo*)+1733>
=> 0x65c845 <js::jit::NewBaselineFrameInspector(js::jit::TempAllocator*, js::jit::BaselineFrame*, js::jit::CompileInfo*)+1733>:	cmpq   $0x0,0x10(%rcx)
   0x65c84a <js::jit::NewBaselineFrameInspector(js::jit::TempAllocator*, js::jit::BaselineFrame*, js::jit::CompileInfo*)+1738>:	cmove  %rcx,%rax


This is a GC topcrasher in fuzzing right now. Marking s-s due to GC and fuzzblocker due to frequency. The runtime flags for this issue might not all be required but I'm traveling right now and can't confirm which ones are.

Comment 1

[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/629c8aac3ece
user:        Brian Hackett
date:        Fri Jan 23 12:42:34 2015 -0700
summary:     Bug 934502 - Remove unnecessary pushedArgumentSlots, track argument slots explicitly in safepoints, r=jandem.

This iteration took 237.416 seconds to run.

Comment 2

[Shu-yu Guo [:shu]]

Under DEBUG the crash is on accessing a JSObject::type_, which has been forwarded and is the poison 0xbad0bad1 pattern.

Comment 3

[Steve Fink [:sfink] [:s:]]

Attachment: bad14.2.js

Here's another testcase that crashes immediately.

Comment 4

[Steve Fink [:sfink] [:s:]]

I do not get the same crash with the testcase from comment 0, but I do get a different crash.

For the code in comment 3 (attachment 8554951 [details]) I get an immediate crash trying to access nursery memory.

Both of these (seeing 0xbad0bad1 and nursery memory with 0x2b2b2b2b) point to something not getting marked, probably some JIT code. Given the regressing patch, I tried making MarkExtraActualArguments mark everything again (|this| and the formals). That resolved my comment 3 crash but not the comment 0 crash.

I more or less understand what the patch is doing, but something is going wrong and the new safepoint-based marking is not marking everything that it used to. Unfortunately, I don't have time to dig into it further tonight, but I suspect it'll be easy for bhackett.

Comment 5

[Brian Hackett [Laid off!]]

Are all these crashes with the backtracking allocator, or is anyone seeing them with LSRA?  For me the comment 3 testcase is fixed by bug 1125770, though the comment 0 testcase still crashes.

Comment 6

[Christian Holler (:decoder)]

I made a few checks in FuzzManager and it looks like the backtracking allocator is always involved. Do you suggest that the test in comment 3 is a different bug? They appeared at the same time for me and are both highly frequent, that's why I thought they're the same.

Comment 7

[Brian Hackett [Laid off!]]

(In reply to Christian Holler (:decoder) from comment #6)
> I made a few checks in FuzzManager and it looks like the backtracking
> allocator is always involved. Do you suggest that the test in comment 3 is a
> different bug? They appeared at the same time for me and are both highly
> frequent, that's why I thought they're the same.

Yes, the test in comment 3 is a different bug, though it is a dupe of bug 1125770.

Comment 8

[Brian Hackett [Laid off!]]

The patch in bug 1125770 was an incorrect fix, I posted a new patch there which also fixes this bug.