1660293 - Assertion failure: lock_.ownedByCurrentThread(), at gc/StoreBuffer.h:397

Status: VERIFIED FIXED

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

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20200820-920ef04bf423 (debug build, run with --fuzzing-safe --ion-offthread-compile=off):

try {
function varying(mapColor, keyColor) {
  enqueueMark(`set-color-${keyColor}`);
  enqueueMark("yield");
  startgc(100000);
}
for (const mapColor of ['gray', 'black'])
    varying(mapColor, 0x7fff);
} catch (exc) {}
oomAfterAllocations(100);

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x0000555556cecc29 in js::InternalBarrierMethods<JS::Value>::postBarrier (vp=0x7ffff4df4568, prev=..., next=...) at js/src/gc/StoreBuffer.h:397
#1  0x00005555570bbae0 in js::BarrierMethods<JS::Value>::postWriteBarrier (v=0x7ffff4df4568, prev=..., next=...) at dist/include/js/Value.h:1141
#2  JS::Heap<JS::Value>::postWriteBarrier (this=<optimized out>, prev=..., next=...) at dist/include/js/RootingAPI.h:365
#3  JS::Heap<JS::Value>::set (this=<optimized out>, newPtr=...) at dist/include/js/RootingAPI.h:344
#4  JS::Heap<JS::Value>::operator=(JS::Heap<JS::Value>&&) (this=<optimized out>, other=<optimized out>) at dist/include/js/RootingAPI.h:322
#5  JS::GCVector<JS::Heap<JS::Value>, 0ul, js::SystemAllocPolicy>::sweep (this=0x7ffff602a558) at dist/include/js/GCVector.h:162
#6  0x00005555570bb7dc in JS::StructGCPolicy<JS::GCVector<JS::Heap<JS::Value>, 0ul, js::SystemAllocPolicy> >::sweep (tp=<optimized out>) at dist/include/js/GCPolicyAPI.h:75
#7  JS::WeakCache<JS::GCVector<JS::Heap<JS::Value>, 0ul, js::SystemAllocPolicy> >::sweep (this=<optimized out>, sbToLock=0x7ffff7105770 <_IO_stdfile_2_lock>) at dist/include/js/SweepingAPI.h:101
#8  0x00005555575d6aeb in SweepAllWeakCachesOnMainThread(JSRuntime*)::$_8::operator()(JS::detail::WeakCacheBase*, JS::Zone*) const (this=<optimized out>, cache=0x7ffff602a538, zone=<optimized out>) at js/src/gc/GC.cpp:5324
#9  IterateWeakCaches<SweepAllWeakCachesOnMainThread(JSRuntime*)::$_8>(JSRuntime*, SweepAllWeakCachesOnMainThread(JSRuntime*)::$_8) (rt=0x7ffff6029000, f=...) at js/src/gc/GC.cpp:5281
#10 SweepAllWeakCachesOnMainThread (rt=0x7ffff6029000) at js/src/gc/GC.cpp:5320
#11 js::gc::GCRuntime::beginSweepingSweepGroup (this=<optimized out>, fop=<optimized out>, budget=...) at js/src/gc/GC.cpp:5424
#12 0x000055555761a471 in sweepaction::SweepActionSequence::run (this=0x7ffff601b0b0, args=...) at js/src/gc/GC.cpp:6093
#13 0x0000555557608f27 in sweepaction::SweepActionForEach<js::gc::SweepGroupsIter, JSRuntime*>::run (this=0x7ffff60256a0, args=...) at js/src/gc/GC.cpp:6128
#14 0x00005555575dae83 in js::gc::GCRuntime::performSweepActions (this=0x7ffff6029768, budget=...) at js/src/gc/GC.cpp:6260
#15 0x00005555575e00a8 in js::gc::GCRuntime::incrementalSlice (this=0x7ffff6029768, budget=..., gckind=..., reason=<optimized out>, session=...) at js/src/gc/GC.cpp:6841
#16 0x00005555575e3024 in js::gc::GCRuntime::gcCycle (this=0x7ffff6029768, nonincrementalByAPI=25, budget=..., gckind=..., reason=<optimized out>) at js/src/gc/GC.cpp:7248
#17 0x00005555575e4c0d in js::gc::GCRuntime::collect (this=0x7ffff6029768, nonincrementalByAPI=<optimized out>, budget=..., gckindArg=..., reason=JS::GCReason::FINISH_GC) at js/src/gc/GC.cpp:7483
#18 0x00005555575aba9d in js::gc::GCRuntime::finishGC (this=0x7ffff6029768, reason=JS::GCReason::FINISH_GC) at js/src/gc/GC.cpp:7592
#19 0x00005555575b3c4c in JS::FinishIncrementalGC (cx=0x7ffff6027000, reason=JS::GCReason::FINISH_GC) at js/src/gc/GC.cpp:8410
#20 js::gc::FinishGC (cx=0x7ffff6027000, reason=JS::GCReason::FINISH_GC) at js/src/gc/GC.cpp:7786
#21 0x0000555556b4c69b in CancelOffThreadJobsForRuntime (cx=0x7ffff6027000) at js/src/shell/js.cpp:423
#22 main::$_5::operator() (this=0x7fffffffd9e0) at js/src/shell/js.cpp:11527
#23 mozilla::ScopeExit<main::$_5>::~ScopeExit (this=0x7fffffffd9e0) at dist/include/mozilla/ScopeExit.h:106
#24 0x0000555556b44443 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:11583
rax	0x5555557d7474	93824994866292
rbx	0x7ffff602c510	140737320764688
rcx	0x555558515a88	93825042307720
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffd060	140737488343136
rsp	0x7fffffffd030	140737488343088
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f9de00	140737353735680
r10	0x58	88
r11	0x7ffff6dac7a0	140737334921120
r12	0x7fffffffd078	140737488343160
r13	0xfff9800000000000	-1829587348619264
r14	0x7ffff4df4568	140737301661032
r15	0x7fffffffd078	140737488343160
rip	0x555556cecc29 <js::InternalBarrierMethods<JS::Value>::postBarrier(JS::Value*, JS::Value const&, JS::Value const&)+553>
=> 0x555556cecc29 <js::InternalBarrierMethods<JS::Value>::postBarrier(JS::Value*, JS::Value const&, JS::Value const&)+553>:	movl   $0x18d,0x0
   0x555556cecc34 <js::InternalBarrierMethods<JS::Value>::postBarrier(JS::Value*, JS::Value const&, JS::Value const&)+564>:	callq  0x555556bd4b0e <abort()>

Marking s-s as a start until investigated, since GC is involved and this is a locking issue as well.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Jason Kratzer [:jkratzer]]

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20200820212107-e375b85cfba3.
The bug appears to have been introduced in the following build range:
> Start: 74f73190afad2bbde97bd6009430b87445718a01 (20200616184413)
> End: 934e959205abe817c23015c326cff2413e1f040c (20200616184513)
> Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=74f73190afad2bbde97bd6009430b87445718a01&tochange=934e959205abe817c23015c326cff2413e1f040c

Comment 3

[Jon Coppeard (:jonco)]

Attachment: Bug 1660293 - Lock store buffer while sweeping weak caches on main thread after OOM r?sfink

Comment 4

[Jon Coppeard (:jonco)]

Comment on attachment 9171727 [details]
Bug 1660293 - Lock store buffer while sweeping weak caches on main thread after OOM r?sfink

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Very difficult (requires triggering OOM and then exploiting race condition).
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which older supported branches are affected by this flaw?: 79 onwards
• If not all supported branches, which bug introduced the flaw?: Bug 1645377
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Same patch should apply.
• How likely is this patch to cause regressions; how much testing does it need?: Unlikely to cause regressions. We've fixed a couple of similar issues in the same manner already.

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Comment on attachment 9171727 [details]
Bug 1660293 - Lock store buffer while sweeping weak caches on main thread after OOM r?sfink

Approved to land and uplift

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/autoland/rev/d9d033eb45390bd30fc6181158a2db4ffb91faca

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7477fda8a898

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/d9d033eb4539

Comment 9

[Jason Kratzer [:jkratzer]]

Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20200829091226-fdf95334aded.