Closed
Bug 1530643
Opened 6 years ago
Closed 6 years ago
Assertion failure: get() (dereferencing a UniquePtr containing nullptr), at dist/include/mozilla/UniquePtr.h:302 with OOM
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla67
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox65 | --- | wontfix |
firefox66 | --- | wontfix |
firefox67 | --- | fixed |
People
(Reporter: decoder, Assigned: jonco)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, bugmon, testcase, Whiteboard: [jsbugmon:update])
Attachments
(1 file)
(deleted),
patch
|
sfink
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision d97cc5b9eeae (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off):
for (var i = 1; i < 100; ++i) {
try {
oomAtAllocation(i, i);
} catch (e) {}
}
evalInWorker("");
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 mozilla::UniquePtr<js::gc::SweepAction<js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&>, JS::DeletePolicy<js::gc::SweepAction<js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&> > >::operator-> (this=<optimized out>) at dist/include/mozilla/UniquePtr.h:302
#1 sweepaction::SweepActionSequence<js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&>::init (count=<optimized out>, acts=<optimized out>, this=<optimized out>) at js/src/gc/GC.cpp:6259
#2 sweepaction::Sequence<js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&, mozilla::UniquePtr<...> (first=...) at js/src/gc/GC.cpp:6401
#3 js::gc::GCRuntime::initSweepActions (this=this@entry=0x7ffff4d936b8) at js/src/gc/GC.cpp:6453
#4 0x0000555555ff54c8 in js::gc::GCRuntime::init (this=this@entry=0x7ffff4d936b8, maxbytes=maxbytes@entry=8388608, maxNurseryBytes=maxNurseryBytes@entry=2097152) at js/src/gc/GC.cpp:1292
#5 0x0000555555beddeb in JSRuntime::init (this=this@entry=0x7ffff4d93000, cx=cx@entry=0x7ffff4d7a000, maxbytes=maxbytes@entry=8388608, maxNurseryBytes=maxNurseryBytes@entry=2097152) at js/src/vm/Runtime.cpp:205
#6 0x0000555555b210de in js::NewContext (maxBytes=8388608, maxNurseryBytes=2097152, parentRuntime=<optimized out>) at js/src/vm/JSContext.cpp:159
#7 0x0000555555860045 in WorkerMain (input=<optimized out>) at js/src/shell/js.cpp:3977
#8 0x0000555555863102 in js::detail::ThreadTrampoline<void (&)(WorkerInput*), WorkerInput*&>::callMain<0ul> (this=0x7ffff4d770f0) at js/src/threading/Thread.h:239
#9 js::detail::ThreadTrampoline<void (&)(WorkerInput*), WorkerInput*&>::Start (aPack=0x7ffff4d770f0) at js/src/threading/Thread.h:232
#10 0x00007ffff7bc16ba in start_thread (arg=0x7ffff68ff700) at pthread_create.c:333
#11 0x00007ffff6c2c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
rax 0x555557c32280 93825032987264
rbx 0x7ffff68fe530 140737330013488
rcx 0x555556b03410 93825014969360
rdx 0x0 0
rsi 0x7ffff6eeb770 140737336227696
rdi 0x7ffff6eea540 140737336223040
rbp 0x7ffff68fe5e0 140737330013664
rsp 0x7ffff68fe3f0 140737330013168
r8 0x7ffff6eeb770 140737336227696
r9 0x7ffff68ff700 140737330018048
r10 0x58 88
r11 0x7ffff6b927a0 140737332717472
r12 0x0 0
r13 0x6 6
r14 0x555557c32878 93825032988792
r15 0x7ffff4def600 140737301640704
rip 0x555555fe9e99 <js::gc::GCRuntime::initSweepActions()+2937>
=> 0x555555fe9e99 <js::gc::GCRuntime::initSweepActions()+2937>: movl $0x0,0x0
0x555555fe9ea4 <js::gc::GCRuntime::initSweepActions()+2948>: ud2
Assignee | ||
Comment 1•6 years ago
|
||
When initialising SweepActionSequence we need to check for allocation failure for any of the passed in SweepActions.
Assignee: nobody → jcoppeard
Attachment #9047037 -
Flags: review?(sphink)
Updated•6 years ago
|
Attachment #9047037 -
Flags: review?(sphink) → review+
Updated•6 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 2•6 years ago
|
||
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/ad30dc53e38e
user: Nicholas Nethercote
date: Fri Aug 10 18:00:29 2018 +1000
summary: Bug 1481998 - Make mozilla::Hash{Map,Set}'s entry storage allocation lazy. r=luke,sfink
This iteration took 1.670 seconds to run.
Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/70b353cfbbf3
Check for allocation failure when initialising sweep actions r=sfink
Comment 4•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Comment 5•6 years ago
|
||
We're a week from 66 going to RC, so I think this can ride the trains. Feel free to nominate for Beta uplift if you feel strongly otherwise.
status-firefox65:
--- → wontfix
status-firefox66:
--- → wontfix
status-firefox-esr60:
--- → unaffected
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•