Assertion failure: currentChunk_ < maxChunkCount(), at js/src/gc/Nursery.h:350
Categories
(Core :: JavaScript: GC, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox67 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | --- | unaffected |
firefox70 | --- | unaffected |
firefox71 | --- | fixed |
People
(Reporter: decoder, Assigned: pbone)
References
(Regression)
Details
(4 keywords, Whiteboard: [jsbugmon:update])
Attachments
(1 file)
The following testcase crashes on mozilla-central revision c31591e0b66f (build with --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off):
try {
var root = {};
f45(root, 17);
function f45(parent, depth) {
f45(parent.a41 = {}, depth);
}
} catch (exc) {}
gcparam('maxNurseryBytes', 256 * 1024);
gczeal(7, 1);
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 js::Nursery::freeSpace (this=this@entry=0x7ffff5f2c300) at js/src/gc/Nursery.h:350
#1 0x000055555619cb20 in js::Nursery::usedSpace (this=0x7ffff5f2c300) at js/src/gc/Nursery.h:345
#2 js::Nursery::doCollection (this=this@entry=0x7ffff5f2c300, reason=reason@entry=JS::GCReason::DESTROY_RUNTIME, tenureCounts=...) at js/src/gc/Nursery.cpp:1000
#3 0x000055555619d98e in js::Nursery::collect (this=0x7ffff5f2c300, reason=reason@entry=JS::GCReason::DESTROY_RUNTIME) at js/src/gc/Nursery.cpp:920
#4 0x0000555556113007 in js::gc::GCRuntime::minorGC (this=this@entry=0x7ffff5f29718, reason=reason@entry=JS::GCReason::DESTROY_RUNTIME, phase=phase@entry=js::gcstats::PhaseKind::EVICT_NURSERY_FOR_MAJOR_GC) at js/src/gc/GC.cpp:7534
#5 0x00005555561406eb in js::gc::GCRuntime::gcCycle (this=this@entry=0x7ffff5f29718, nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., gckind=..., reason=reason@entry=JS::GCReason::DESTROY_RUNTIME) at js/src/gc/GC.cpp:7101
#6 0x0000555556140fce in js::gc::GCRuntime::collect (this=this@entry=0x7ffff5f29718, nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., gckindArg=..., reason=reason@entry=JS::GCReason::DESTROY_RUNTIME) at js/src/gc/GC.cpp:7321
#7 0x00005555561415b5 in js::gc::GCRuntime::gc (this=this@entry=0x7ffff5f29718, gckind=gckind@entry=GC_NORMAL, reason=reason@entry=JS::GCReason::DESTROY_RUNTIME) at js/src/gc/GC.cpp:7403
#8 0x0000555555cbc65a in JSRuntime::destroyRuntime (this=this@entry=0x7ffff5f29000) at js/src/vm/Runtime.cpp:289
#9 0x0000555555b61198 in js::DestroyContext (cx=0x7ffff5f27000) at js/src/vm/JSContext.cpp:197
[...]
#12 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:11382
rax 0x555557fd70e0 93825036808416
rbx 0x7ffff5f2c300 140737319715584
rcx 0x7ffff6c1c2dd 140737333281501
rdx 0x0 0
rsi 0x555556ed27b8 93825018963896
rdi 0x7ffff6eea540 140737336223040
rbp 0x7fffffffce00 140737488342528
rsp 0x7fffffffcdf0 140737488342512
r8 0x7ffff6eeb770 140737336227696
r9 0x7ffff7fe6cc0 140737354034368
r10 0x58 88
r11 0x7ffff6b927a0 140737332717472
r12 0x1 1
r13 0x7ffff5f29000 140737319702528
r14 0x100000 1048576
r15 0x7ffff5f27000 140737319694336
rip 0x5555561a0639 <js::Nursery::freeSpace() const+265>
=> 0x5555561a0639 <js::Nursery::freeSpace() const+265>: movl $0x0,0x0
0x5555561a0644 <js::Nursery::freeSpace() const+276>: ud2
Marking s-s until investigated because this involves GC.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Web content can't change maxNurseryBytes so is this a problem in practice? Is the problem due to changing this value, or the value itself? If the latter, is that a value we'd ever ship by default in the future?
Assignee | ||
Comment 3•6 years ago
|
||
Daniel.
No, web content can't change this value.
We're very unlikely to ship with a value < 1MB.
I like to find the cause of these bugs before removing the security protection though, just in case we don't have the whole picture.
Assignee | ||
Comment 4•6 years ago
|
||
Hi Daniel,
This bug is specific to a debugging mode (zeal mode) of the GC, it's not security-sensitive. You may remove it from the security groups.
Thanks.
Assignee | ||
Comment 5•6 years ago
|
||
Entering generational zeal mode can reduce the nursery size which causes
this assertion failure when the maximum size becomes smaller than the
current size.
This patch evicts the nursery before entering generational zeal mode.
Note that we already do this when leaving generational zeal mode. The
assumption was that zeal mode is at least as large as any normal
configuration.
Updated•6 years ago
|
Comment 7•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•3 years ago
|
Description
•