992535 - Soundcloud crashes with Generational GC

Status: VERIFIED FIXED

(Core :: JavaScript: GC, defect)

Description

[Hannes Verschore [:h4writer]]

When trying to listen to something on SoundCloud the browser crashes. (This is on linux

Steps to repro:
1) Go to soundcloud.com
2) Click on "Sign in"
3) Click on "Sign in using Google plus" (I think other options work too, but this works for me)
4) Fill your google account
5) Click again on "Sign in using Google plus" (I think this is a bug in soundcloud)
6) Search for "David Guetta"
7) Try to play the mix
8) Crash

https://crash-stats.mozilla.com/report/index/b4c79117-b8c8-4673-82d1-570e52140405

The crash points into GGC code, so I think this is also caused by GGC. I did a bisect on the nightlies: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa163ff81a3&tochange=4f3443da36a1

This is the day GGC was enabled. So I didn't bother bisecting further...


Note: I split this off from bug 980886, since I think they are not related, since "Assertion failure: MIR instruction returned value with unexpected type", has a masm.breakpoint(). As a result it should also crash, but should give another backtrace. (I'm gonna look into bug 980886 and fix it. If I get any doubt that other bug might have caused this, I'll report.)

Comment 1

[Terrence Cole [:terrence]]

Yay STR! \o/

This has been a topcrash since GGC landed. So far only Jon has been able to repro and then I think only sporadically. I owe you a beer (or other beverage of your choice) next time we're in the same locality!

Comment 2

[Paul Silaghi, QA [:pauly]]

Dupe of bug 991755

Comment 3

[Jon Coppeard (:jonco)]

Can reproduce.  It crashes marking element 774 in a 1109 element Array, which is a JSObject pointer into swept nursery.

We're collecting because the store buffer is full when running JIT code.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3319649 in js::gc::GetGCThingRuntime (thing=0x2b2b2b2b2b2b2b2b) at ../../dist/include/js/HeapAPI.h:133
133	    return *reinterpret_cast<JS::shadow::Runtime **>(addr);
(gdb) bt
#0  0x00007ffff3319649 in js::gc::GetGCThingRuntime (thing=0x2b2b2b2b2b2b2b2b) at ../../dist/include/js/HeapAPI.h:133
#1  0x00007ffff332ff6f in js::gc::Cell::isTenured (this=0x2b2b2b2b2b2b2b2b) at /home/jon/work/dev/js/src/gc/Heap.h:1070
#2  0x00007ffff332fedd in js::gc::Cell::arenaHeader (this=0x2b2b2b2b2b2b2b2b) at /home/jon/work/dev/js/src/gc/Heap.h:979
#3  0x00007ffff333f929 in js::gc::Cell::tenuredZone (this=0x2b2b2b2b2b2b2b2b) at /home/jon/work/dev/js/src/gc/Heap.h:1039
#4  0x00007ffff333f905 in js::gc::BarrieredCell<js::Shape>::zone (this=0x2b2b2b2b2b2b2b2b) at /home/jon/work/dev/js/src/gc/Barrier.h:185
#5  0x00007ffff333f705 in js::gc::BarrieredCell<js::ObjectImpl>::zone (this=0x7fffdde25f40) at /home/jon/work/dev/js/src/vm/ObjectImpl.h:918
#6  0x00007ffff3465488 in js::Nursery::moveToTenured (this=0x7fffdf83bd90, trc=0x7fffffff3b60, 
    src=(JSObject *) 0x7fffdde25f40 Cannot access memory at address 0x2b2b2b2b2b2b2b2b) at /home/jon/work/dev/js/src/gc/Nursery.cpp:531
#7  0x00007ffff3465ec0 in js::Nursery::MinorGCCallback (jstrc=0x7fffffff3b60, thingp=0x7fffffff37e8, kind=JSTRACE_OBJECT)
    at /home/jon/work/dev/js/src/gc/Nursery.cpp:646
#8  0x00007ffff3451a32 in MarkInternal (trc=0x7fffffff3b60, thingp=0x7fffffff37e8) at /home/jon/work/dev/js/src/gc/Marking.cpp:222
#9  0x00007ffff3460157 in js::gc::MarkKind (trc=0x7fffffff3b60, thingp=0x7fffffff37e8, kind=JSTRACE_OBJECT) at /home/jon/work/dev/js/src/gc/Marking.cpp:492
#10 0x00007ffff3460abd in MarkValueInternal (trc=0x7fffffff3b60, v=0x7fffc1769840) at /home/jon/work/dev/js/src/gc/Marking.cpp:612
#11 0x00007ffff3461292 in js::gc::MarkArraySlots (trc=0x7fffffff3b60, len=1109, vec=0x7fffc1768010, name=0x7ffff41e32a7 <.L.str61> "objectElements")
    at /home/jon/work/dev/js/src/gc/Marking.cpp:727
#12 0x00007ffff3ad3582 in js::ObjectImpl::markChildren (this=0x7fffbf1afd60, trc=0x7fffffff3b60) at /home/jon/work/dev/js/src/vm/ObjectImpl.cpp:380
#13 0x00007ffff3461c38 in js::gc::MarkChildren (trc=0x7fffffff3b60, obj=(JSObject *) 0x7fffbf1afd60 [object Array]) at /home/jon/work/dev/js/src/gc/Marking.cpp:1116
#14 0x00007ffff3469728 in js::gc::StoreBuffer::WholeCellEdges::mark (this=0x7fffbacb8048, trc=0x7fffffff3b60) at /home/jon/work/dev/js/src/gc/StoreBuffer.cpp:60
#15 0x00007ffff34bc562 in js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::mark (this=0x7fffdf83be50, owner=0x7fffdf83be08, 
    trc=0x7fffffff3b60) at /home/jon/work/dev/js/src/gc/StoreBuffer.cpp:172
#16 0x00007ffff34b8867 in js::gc::StoreBuffer::markWholeCells (this=0x7fffdf83be08, trc=0x7fffffff3b60) at /home/jon/work/dev/js/src/gc/StoreBuffer.h:481
#17 0x00007ffff3466085 in js::Nursery::collect (this=0x7fffdf83bd90, rt=0x7fffdf83b000, reason=JS::gcreason::FULL_STORE_BUFFER, pretenureTypes=0x7fffffff3ca0)
    at /home/jon/work/dev/js/src/gc/Nursery.cpp:712
#18 0x00007ffff38e5722 in js::MinorGC (cx=0x7fffda42c480, reason=JS::gcreason::FULL_STORE_BUFFER) at /home/jon/work/dev/js/src/jsgc.cpp:5096
#19 0x00007ffff38e5896 in js::gc::GCIfNeeded (cx=0x7fffda42c480) at /home/jon/work/dev/js/src/jsgc.cpp:5116
#20 0x00007ffff3882537 in js::InvokeInterruptCallback (cx=0x7fffda42c480) at /home/jon/work/dev/js/src/jscntxt.cpp:1020
#21 0x00007ffff332b391 in js::CheckForInterrupt (cx=0x7fffda42c480) at /home/jon/work/dev/js/src/jscntxt.h:842
#22 0x00007ffff37fdfc2 in js::jit::InterruptCheck (cx=0x7fffda42c480) at /home/jon/work/dev/js/src/jit/VMFunctions.cpp:509
#23 0x00007ffff37fdf54 in js::jit::CheckOverRecursed (cx=0x7fffda42c480) at /home/jon/work/dev/js/src/jit/VMFunctions.cpp:130

Comment 4

[Jon Coppeard (:jonco)]

Attachment: backtraces.txt

Here are some more backtraces when I've seen this crash.

Comment 5

[Terrence Cole [:terrence]]

Attachment: missing_barrier_arraypopshift-v0.diff

Hannes got a dump of the ion codegen and pointed the finger right at arraypopshiftv. Visual inspection quickly found this missing barrier. Seems to solve the crash locally for me.

Comment 6

[Terrence Cole [:terrence]]

Detailed explanation:

ArrayPopShift in the shift case needs to memmove the array's memory one slot to the left. If we had inserted a store buffer entry for the element at offset N, this memmove would move the Value we need to mark to N-1. Given the right circumstances, this would leave slot N-1 unmarked in the next minor GC and the pointer dangling. The specific call was moveDenseElementsUnbarriered. Unbarriered in this case was supposed to be for /pre/ barriers, which are excessively expensive in this case. The solution is just to add the cheap post-barrier.

Comment 7

[Andrew McCreight [:mccr8]]

Now that GGC is on for trunk, please avoid discussing memory corruption in open bugs.

Comment 8

[Terrence Cole [:terrence]]

D'oh! Thanks Andrew!

Comment 9

[Terrence Cole [:terrence]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/04a44359d024

Comment 10

[Hannes Verschore [:h4writer]]

On AWFY I see a regression for octane-deltablue(7%)/octane-earleyboyer(13%)/octane-raytrace(25%). This could be caused by this patch or by bug 984101.

(http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=30c9030026f1&tochange=c2adda06f871)

http://arewefastyet.com/?a=b&view=regress#machine=17&view=breakdown&suite=octane

Comment 11

[Hannes Verschore [:h4writer]]

Oh I forgot to mention this is on the windows 8 slave.

Comment 12

[Carsten Book [:Tomcat]]

landed on central https://hg.mozilla.org/mozilla-central/rev/04a44359d024

Comment 17

[Paul Silaghi, QA [:pauly]]

I got some different signatures by trying to reproduce the crash using the STR in comment 0 on Nightly 2014-04-05, Win 7 x64:
https://crash-stats.mozilla.com/report/index/d951db9a-e021-4075-987b-c853b2140415
https://crash-stats.mozilla.com/report/index/f4effa3c-497c-4f53-b161-9ee0e2140415

Anyway, no sign of crashes in nightly 31.0a1 (2014-04-15).
Marking the bug as verified.