876549 - Crash [@ js::gc::Cell::tenuredZone] or Opt-Crash [@ markIfUnmarked] with ParallelArray

Status: RESOLVED DUPLICATE of bug 876495

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision a39263b0c896 (run with --ion-eager):


var p = new ParallelArray([0]);
m = p.map(function() { gczeal(2,3); }, { mode : 'compile'});
evaluate('\
var o0 = [];\
var o4 = {};\
var o5 = Math;\
function f2(o) { o.g2 = function() {}; };\
function f6(o) { o[3] = o; };\
for(var i=0; i<20; i++) {\
    f6(o0);\
    f2(o5);\
    f6(o4);\
}\
');

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Christian Holler (:decoder)]

Opt-crash trace:


Program received signal SIGSEGV, Segmentation fault.
markIfUnmarked (cell=0xfffa000000000000, this=<optimized out>, color=0) at ../gc/Heap.h:692
692             if (*word & mask)
#0  markIfUnmarked (cell=0xfffa000000000000, this=<optimized out>, color=0) at ../gc/Heap.h:692
#1  markIfUnmarked (color=0, this=0xfffa000000000000) at ../gc/Heap.h:981
#2  PushMarkStack (thing=0xfffa000000000000, gcmarker=0x15fde28) at js/src/gc/Marking.cpp:776
#3  processMarkStackTop (budget=..., this=0x15fde28) at js/src/gc/Marking.cpp:1400
#4  js::GCMarker::drainMarkStack (this=0x15fde28, budget=...) at js/src/gc/Marking.cpp:1464
#5  0x0000000000497904 in DrainMarkStack (phase=js::gcstats::PHASE_MARK, sliceBudget=..., rt=0x15fdc10) at js/src/jsgc.cpp:3773
#6  IncrementalCollectSlice (rt=<optimized out>, budget=<optimized out>, reason=JS::gcreason::DEBUG_GC, gckind=js::GC_NORMAL) at js/src/jsgc.cpp:4257
#7  0x0000000000499798 in GCCycle (rt=0x15fdc10, incremental=<optimized out>, budget=<optimized out>, gckind=js::GC_NORMAL, reason=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:4415
rdx     0xfc0b0 -1688849859231568
=> 0x62e9ca <js::GCMarker::drainMarkStack(js::SliceBudget&)+410>:       mov    (%rdx),%r9


S-s due to access to invalid memory address and GC involved.

Comment 3

[Christian Holler (:decoder)]

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

The first bad revision is:
changeset:   132973:d25e852fdb68
user:        Boris Zbarsky
date:        Fri May 24 22:38:09 2013 -0400
summary:     Bug 875939.  Make passing a Rooted<T> or Handle<T> to a function taking |const T&| not be a gc hazard.  r=terrence

This iteration took 327.055 seconds to run.

Comment 4

[Christian Holler (:decoder)]

Not sure if the bisect is correct. Needinfo from bz based on comment 3 :)

Comment 5

[Christian Holler (:decoder)]

Bisection is not correct, bz confirmed this is reproducing without his changeset. Not sure why autoBisect is picking the wrong cset here.

Ccing ParallelArray devs as a start :)

Comment 6

[Boris Zbarsky [:bzbarsky]]

The testcase crashes for me with rev b1c234d32193, which is the parent of the changeset from comment 3, in a debug shell on MacOS (so 64-bit).  The stack is slightly different from the opt stack from comment 2, but also goes through processMarkStackTop.  In that function we seem to have an obj2 a bunch of whose pointer members are 0xfffa000000000000 (which quacks like a NaN to me?).

Comment 7

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

(In reply to Christian Holler (:decoder) from comment #5)
> Bisection is not correct, bz confirmed this is reproducing without his
> changeset. Not sure why autoBisect is picking the wrong cset here.

autoBisect may give incorrect results when some intermediate changeset is marked incorrectly as pass/fail, but we'll have to look at logs to be sure..

Comment 8

[Christian Holler (:decoder)]

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

Comment 9

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 495b385ae811).
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   133116:00b0dc4c196e
user:        Hannes Verschore
date:        Tue May 28 15:09:25 2013 +0200
summary:     Bug 876649: IonMonkey: Temporary disable MSetElementCache when no dense write is seen, r=jandem

This iteration took 11.429 seconds to run.

Comment 10

[Boris Zbarsky [:bzbarsky]]

That would suggest the initial problem was caused by bug 774006?

Comment 11

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

I re-ran autoBisect and got this:

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   132964:3835cbed5915
user:        Nicolas B. Pierron
date:        Fri May 24 14:58:08 2013 -0700
summary:     Bug 774006 - IonMonkey: Implement SetElementIC for integer indexes. r=h4writer

bz, that's right.

Comment 12

[Nicolas B. Pierron [:nbp]]

This bug does not involve anything related to parallel array.  I guess this is just a duplicate of Bug 876495.  The reason is that it does an out-of-bound access to the array, which has been disabled by Bug 876649.

I don't think there is any need to add this test case as it is /identical/ to the one reported in Bug 876495.