1820839 - Assertion failure: desired && OffsetFromAligned(desired, allocGranularity) == 0, gc/Memory.cpp:258

Status: NEW

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

Description

[lukas.bernhard]

Steps to reproduce:

During fuzzing, I found a (flaky) crash with the following stack trace. The line numbers in the stack trace are a bit off (maybe due to lto?).

#0  0x00005651352ce99f in js::gc::TryToAlignChunk<false> (length=1048576, alignment=1048576, aRegion=<optimized out>, aRetainedRegion=<optimized out>)     at js/src/gc/Memory.cpp:715
#1  js::gc::MapAlignedPagesRandom (length=1048576, alignment=1048576) at js/src/gc/Memory.cpp:559
#2  js::gc::MapAlignedPages (length=1048576, alignment=1048576) at js/src/gc/Memory.cpp:448
#3  0x000056513525f8c2 in js::gc::TenuredChunk::allocate (gc=0x73f3db72728) at js/src/gc/Allocator.cpp:773
#4  js::gc::GCRuntime::getOrAllocChunk (this=0x73f3db72728, lock=...) at js/src/gc/Allocator.cpp:695
#5  0x00005651352d175b in js::Nursery::allocateNextChunk (this=0x73f3db75098, chunkno=0, lock=...) at js/src/gc/Nursery.cpp:1703
#6  0x00005651352d08fd in js::Nursery::initFirstChunk (this=0x73f3db75098, lock=...) at js/src/gc/Nursery.cpp:331
#7  0x00005651352d07c5 in js::Nursery::init (this=0x73f3db75098, lock=...) at js/src/gc/Nursery.cpp:295
#8  0x0000565135276323 in js::gc::GCRuntime::init (this=0x73f3db72728, maxbytes=8388608) at js/src/gc/GC.cpp:843
#9  0x0000565134cb165a in JSRuntime::init (this=0x73f3db72000, cx=0x6fe30b00, maxbytes=8388608) at js/src/vm/Runtime.cpp:195
#10 0x0000565134af8457 in js::NewContext (maxBytes=8388608, parentRuntime=<optimized out>) at js/src/vm/JSContext.cpp:185
#11 0x0000565134f64376 in JS_NewContext (maxbytes=642345472, parentRuntime=<optimized out>) at js/src/jsapi.cpp:398
#12 0x00005651347b8036 in WorkerMain (input=...) at js/src/shell/js.cpp:4170
#13 0x00005651347b8bda in js::detail::ThreadTrampoline<void (&)(mozilla::UniquePtr<WorkerInput, JS::DeletePolicy<WorkerInput> >), mozilla::UniqueP
tr<WorkerInput, JS::DeletePolicy<WorkerInput> > >::callMain<0ul> (this=0x6fe472e0) at js/src/threading/Thread.h:220
#14 js::detail::ThreadTrampoline<void (&)(mozilla::UniquePtr<WorkerInput, JS::DeletePolicy<WorkerInput> >), mozilla::UniquePtr<WorkerInput, JS::De
letePolicy<WorkerInput> > >::Start (aPack=0x6fe472e0)
    at js/src/threading/Thread.h:209
#15 0x00006d7f2632e402 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#16 0x00006d7f263bc744 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100

My analysis so far:

1. the allocator requests 1048576 bytes/1 MB with alignment 1048576 here
   https://searchfox.org/mozilla-central/rev/3002762e41363de8ee9ca80196d55e79651bcb6b/js/src/gc/Memory.cpp#451
2. the OS allocator returned 1 MB of memory at address 0x56000 (this value I got from the rr trace). Note that the address returned is smaller than the requested alignment.
   The allocation reaches https://searchfox.org/mozilla-central/rev/3002762e41363de8ee9ca80196d55e79651bcb6b/js/src/gc/Memory.cpp#562
3. Inside TryToAlignChunk, variable offsetLower is 0x56000 (exactly the same as the allocated region address, because the mapped address is smaller than the alignment). Hence, lowerStart is computed as 0 here
   https://searchfox.org/mozilla-central/rev/3002762e41363de8ee9ca80196d55e79651bcb6b/js/src/gc/Memory.cpp#737
4. The subsequent call to MapMemoryAt uses the lowerStart (which is 0) as desired, which triggers an assertion violation in debug builds here:
   https://searchfox.org/mozilla-central/source/js/src/gc/Memory.cpp#259
   In release builds, this should be of no consequence as MapMemoryAt will just unmap the returned region and return a nullptr.