From 6aa3331bdb9d1c74fa4f3b6d2f9f2bfbd7106bed Mon Sep 17 00:00:00 2001 From: Moonchild Date: Wed, 25 Feb 2026 14:53:42 +0100 Subject: [PATCH] No issue - Don't assign non-live hash table entry. The problem here is that we use move assignment on a hash table entry that is not live. Although all entries are constructed by `HashTable::createTable`, they may subsequently be destroyed by `HashTableEntry::destroyStoredT()`. Therefore it is not safe to call any methods on a non live entry. This causes a problem for GC barrier wrappers which assume that the object state is valid (and presumably anything that does more than just write the assigned data into memory). The fix is to construct a new entry in-place. Based on work by Jon Coppeard in Bug 2009608 --- js/public/HashTable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/js/public/HashTable.h b/js/public/HashTable.h index d0f7dba41f..90bfcbdbe9 100644 --- a/js/public/HashTable.h +++ b/js/public/HashTable.h @@ -830,7 +830,7 @@ class HashTableEntry if (other->isLive()) { mozilla::Swap(*mem.addr(), *other->mem.addr()); } else { - *other->mem.addr() = mozilla::Move(*mem.addr()); + new (mozilla::KnownNotNull, other->mem.addr()) NonConstT(mozilla::Move(*mem.addr())); destroy(); } mozilla::Swap(keyHash, other->keyHash);