1167860 - crashes checking MOZ_ASSERT(obj->compartment() == obj2->compartment()) in GCMarker::processMarkStackTop

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I run debug builds as my primary browser.  In the past three days, running a build based on https://hg.mozilla.org/mozilla-central/rev/8d8df22fe72d (plus my patch queue as of Wed May 20 18:54:24 2015 -0400), I've crashed three times in GCMarker::processMarkStackTop.

This crash has been during the checking of this assertion on line 1184:
            MOZ_ASSERT(obj->compartment() == obj2->compartment());
with the following problem:

(gdb) p obj->group_.value->compartment_
$5 = (JSCompartment *) 0x4f1ddf80
(gdb) p obj2->group_.value->compartment_
Cannot access memory at address 0x2b2b2b2b2b2b2b3b
(gdb) p obj2->group_.value
$6 = (js::ObjectGroup *) 0x2b2b2b2b2b2b2b2b

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This is a child process crash.

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: gdb session

Comment 3

[Andrew McCreight [:mccr8]]

Off-hand, I'd have guessed this was something like bug 1166277, but it looks like the revision you are using has that patch so that can't be it.

Comment 4

[Carsten Book [:Tomcat]]

just a note that bughunter also found Bug 1168375 which might be the same/related

Comment 5

[Andrew McCreight [:mccr8]]

Bug 1166762 also looks similar.

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

http://forecast.weather.gov/MapClick.php?lat=39.95&lon=-75.17&smap=1&marine=0&unit=1&mp=1 seems to trigger this somewhat reliably for me

Comment 7

[Terrence Cole [:terrence]]

If obj2 was moved, that implicates a missing post-barrier on whatever wrote that slot. The existence of HeapSlot should keep C++ from missing a barrier -- maybe a new MCallOptimize path in ion?

Comment 8

[Terrence Cole [:terrence]]

I was able to repro this quite quickly by opening the link above, then doing |window.open('about:blank')| in the console, then in the child window's console doing |window.setInterval(()=>{window.opener.location.reload()}, 5000)|.

Unfortunately, this doesn't immediately get me closer to a solution because the lack of barrier happened at least 3 writes ago, before the prior minor GC, possibly earlier. I'll need to get rr working again to get further. Been meaning to give that another go anyway.

Comment 9

[Terrence Cole [:terrence]]

I've got it captured in rr now; might as well take the bug.

Comment 10

[Terrence Cole [:terrence]]

As expected, the write missing a store-buffer entry is in the middle of jit-code. As it only takes a couple of minutes to repro, I think the best way to proceed is going to be to bisect.

Comment 11

[Terrence Cole [:terrence]]

Bisection results:

Last Good: f8d7bb0b4f00
First Bad: 322487136b28

changeset:   244263:322487136b28
user:        Brian Hackett <[e-mail]>
date:        Sun May 17 20:12:14 2015 -0600
summary:     Bug 1162199 - Use unboxed objects by default, r=jandem.

Brian, can you take it from here?

Comment 12

[Brian Hackett [Laid off!]]

I can't reproduce this.

Comment 13

[Brian Hackett [Laid off!]]

Attachment: patch

Err, immediately after posting that this started to reproduce.  There actually was a store buffer entry being added for this write, but while the write is to an unboxed expando the store buffer entry is for the original unboxed object.  WholeCellEdges::trace handles this fine, but if the unboxed object is converted to a native before the next minor GC then the expando is not traced by the store buffer.

Comment 14

[Terrence Cole [:terrence]]

Comment on attachment 8612485 [details] [diff] [review]
patch

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

Nice!

Comment 15

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4659ab6d49

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0d4659ab6d49