Closed Bug 1763874 Opened 2 years ago Closed 2 years ago

Tuple elements are not traced properly

Categories

(Core :: JavaScript: GC, defect, P1)

Firefox 101
defect

Tracking

()

RESOLVED FIXED
101 Branch
Tracking Status
firefox101 --- fixed

People

(Reporter: tjc, Assigned: tjc)

Details

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #1747741 +++

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36

Steps to reproduce:

See the attached test file, compacting-gc-nested-tuples.js .

With records and tuples enabled, this test runs a loop 20 times in which it creates a nested tuple. It also calls gczeal(14) to ensure compacting GC.

Actual results:

$ mach jit-test record-tuple/compacting-gc-nested-tuples  -g
(gdb) run
[...]

Thread 9 "JS Helper" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5d05640 (LWP 1268646)]
0x0000555557061095 in js::gc::detail::CellHasStoreBuffer (cell=0xfffe4b4b4b4b4b48) at /home/tjc/gecko-fork/obj-x64-debug/dist/include/js/HeapAPI.h:590
590	  return GetCellChunkBase(cell)->storeBuffer;
(gdb) bt
#0  0x0000555557061095 in js::gc::detail::CellHasStoreBuffer (cell=0xfffe4b4b4b4b4b48)
    at /home/tjc/gecko-fork/obj-x64-debug/dist/include/js/HeapAPI.h:590
#1  0x0000555557061069 in js::gc::IsInsideNursery (cell=0xfffe4b4b4b4b4b48)
    at /home/tjc/gecko-fork/obj-x64-debug/dist/include/js/HeapAPI.h:599
#2  0x00005555570c4205 in js::gc::IsInsideNursery (obj=0xfffe4b4b4b4b4b48)
    at /home/tjc/gecko-fork/obj-x64-debug/dist/include/js/HeapAPI.h:611
#3  0x0000555557eaa811 in js::CheckTracedThing<JSObject> (trc=0x7ffff5d049e8, thing=0xfffe4b4b4b4b4b48)
    at /home/tjc/gecko-fork/js/src/gc/Marking.cpp:189
#4  0x0000555557ed37d8 in DoCallback<JS::Value>(js::GenericTracer*, JS::Value*, char const*)::{lambda(auto:1)#1}::operator()<JSObject*>(JSObject*) const (this=0x7ffff5d04728, thing=0x31499aa730a0) at /home/tjc/gecko-fork/js/src/gc/Marking.cpp:692
#5  0x0000555557ed33d7 in js::MapGCThingTyped<DoCallback<JS::Value>(js::GenericTracer*, JS::Value*, char const*)::{lambda(auto:1)#1}>(JS::Value const&, DoCallback<JS::Value>(js::GenericTracer*, JS::Value*, char const*)::{lambda(auto:1)#1}&&) (val=..., f=...)
    at /home/tjc/gecko-fork/obj-x64-debug/dist/include/js/Value.h:1345
#6  0x0000555557ec3583 in DoCallback<JS::Value> (trc=0x7ffff5d049e0, thingp=0x7ffff693a270, name=0x555555930747 "objectElements")
    at /home/tjc/gecko-fork/js/src/gc/Marking.cpp:691
#7  0x0000555557eb1026 in js::gc::TraceEdgeInternal<JS::Value> (trc=0x7ffff5d049e8, thingp=0x7ffff693a270, 
    name=0x555555930747 "objectElements") at /home/tjc/gecko-fork/js/src/gc/Marking.cpp:732
#8  0x0000555557ec373a in js::gc::TraceRangeInternal<JS::Value> (trc=0x7ffff5d049e8, len=1, vec=0x7ffff693a270, 
    name=0x555555930747 "objectElements") at /home/tjc/gecko-fork/js/src/gc/Marking.cpp:741
#9  0x00005555573ad47d in js::TraceRange<JS::Value> (trc=0x7ffff5d049e8, len=1, vec=0x7ffff693a270, 
    name=0x555555930747 "objectElements") at /home/tjc/gecko-fork/js/src/gc/Tracer.h:271
#10 0x000055555755377f in JSObject::traceChildren (this=0x31499aa74220, trc=0x7ffff5d049e8)
    at /home/tjc/gecko-fork/js/src/vm/JSObject.cpp:3398
#11 0x0000555557e134f4 in UpdateCellPointers<JSObject> (trc=0x7ffff5d049e0, cell=0x31499aa74220)
    at /home/tjc/gecko-fork/js/src/gc/Compacting.cpp:489
#12 0x0000555557e2ea5b in UpdateArenaPointersTyped<JSObject> (trc=0x7ffff5d049e0, arena=0x31499aa74000)
    at /home/tjc/gecko-fork/js/src/gc/Compacting.cpp:495
#13 0x0000555557e2e765 in UpdateArenaPointers (trc=0x7ffff5d049e0, arena=0x31499aa74000)
    at /home/tjc/gecko-fork/js/src/gc/Compacting.cpp:525
#14 0x0000555557e139c0 in UpdateArenaListSegmentPointers (gc=0x7ffff69187a8, arenas=...)
    at /home/tjc/gecko-fork/js/src/gc/Compacting.cpp:549
#15 0x0000555557e66c90 in js::gc::ParallelWorker<ArenaListSegment, ArenasToUpdate>::run (this=0x7fffffff8d48, lock=...)
    at /home/tjc/gecko-fork/js/src/gc/ParallelWork.h:57
#16 0x0000555557e8586e in js::GCParallelTask::runTask (this=0x7fffffff8d48, lock=...)
    at /home/tjc/gecko-fork/js/src/gc/GCParallelTask.cpp:182
#17 0x0000555557e85a55 in js::GCParallelTask::runHelperThreadTask (this=0x7fffffff8d48, lock=...)
    at /home/tjc/gecko-fork/js/src/gc/GCParallelTask.cpp:165
#18 0x00005555574a076f in js::GlobalHelperThreadState::runTaskLocked (this=0x7ffff690e000, task=0x7fffffff8d48, locked=...)
    at /home/tjc/gecko-fork/js/src/vm/HelperThreads.cpp:2653
#19 0x00005555574a054b in js::GlobalHelperThreadState::runOneTask (this=0x7ffff690e000, lock=...)
    at /home/tjc/gecko-fork/js/src/vm/HelperThreads.cpp:2622
#20 0x00005555574f2518 in js::HelperThread::threadLoop (this=0x7ffff693a140, pool=0x7ffff6937280)
    at /home/tjc/gecko-fork/js/src/vm/InternalThreadPool.cpp:271
--Type <RET> for more, q to quit, c to continue without paging--
#21 0x00005555574f2372 in js::HelperThread::ThreadMain (pool=0x7ffff6937280, helper=0x7ffff693a140)
    at /home/tjc/gecko-fork/js/src/vm/InternalThreadPool.cpp:214
#22 0x0000555557525382 in js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::callMain<0ul, 1ul> (this=0x7ffff6917b30) at /home/tjc/gecko-fork/js/src/threading/Thread.h:220
#23 0x000055555752518b in js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::Start (aPack=0x7ffff6917b30) at /home/tjc/gecko-fork/js/src/threading/Thread.h:209
#24 0x00007ffff7ad9947 in start_thread (arg=<optimized out>) at pthread_create.c:435
#25 0x00007ffff7b69a44 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100

Expected results:

The test should pass. I have a patch coming shortly.

Like arrays, tuples have fixed elements. The GC previously assumed that
only arrays can have fixed elements, and so tuple elements weren't being
traced properly.

Attachment #9271543 - Attachment description: WIP: Bug 1763874 - Handle tuples properly in compacting GC → WIP: Bug 1763874 - Handle tuples properly in compacting GC r?sfink
Assignee: nobody → tjc
Status: NEW → ASSIGNED
Attachment #9271543 - Attachment description: WIP: Bug 1763874 - Handle tuples properly in compacting GC r?sfink → WIP: Bug 1763874 - Handle tuples properly in compacting GC r=sfink
Attachment #9271543 - Attachment description: WIP: Bug 1763874 - Handle tuples properly in compacting GC r=sfink → Bug 1763874 - Handle tuples properly in compacting GC r=sfink
Flags: needinfo?(sphink)

From bug 1763883: "I saw both green try builds, so I'm pushing both this and bug 1763874 right now."

Flags: needinfo?(sphink)
Pushed by sfink@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/49ff0bb22975
Handle tuples properly in compacting GC r=sfink

Backed out for causing SM bustages on record-tuple/from.js

Backout link

Push with failures

Failure log 1 // Failure log 2 // Failure log 3

Flags: needinfo?(tjc)

Fixed, see bug 1763883

Flags: needinfo?(tjc)
Pushed by sfink@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/130e136c0583
Handle tuples properly in compacting GC r=sfink
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: