No worries, running with TSAN for such repros would've immediately flushed it out as the global handle system is designed for single-threaded execution and intentionally avoids use of atomics.
Cheers, -Michael On Thu, Dec 13, 2018 at 2:28 AM Kenton Varda <ken...@cloudflare.com> wrote: > On Tue, Dec 11, 2018 at 1:02 PM Kenton Varda <ken...@cloudflare.com> > wrote: > >> On Tue, Dec 11, 2018 at 11:13 AM Michael Lippautz <mlippa...@chromium.org> >> wrote: >> >>> I really hope that handles are only access from the same thread the GC >>> is running on. Otherwise, you would need a v8::Locker to synchronize that >>> access. >>> >> >> Right, the isolate mutex is locked any time we're manipulating handles. >> > > ... or so I thought. > > It turns out in some buggy cases a destructor for a C++ object was > executing without locking the isolate mutex. Before my refactoring, this > resulted in the destruction of a persistent handle, which apparently didn't > cause any visible concurrency issues. After my refactoring, this ended up > invoking SetWeak() on a handle without destroying it. If this happened to > occur at the wrong time during a scavenge, it could cause the object to be > scavenged twice. > > In retrospect I obviously should have thought of this earlier. > > I've now added some asserts and template hacks to catch this class of > error. > > Thanks for the hint and sorry for wasting your time! > > -Kenton > >> -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
