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.
