307273 - Locking doesn't always add objects to rt->gcLocksHash

Status: VERIFIED INVALID

(Core :: JavaScript Engine, defect, P1)

Description

[Blake Kaplan (:mrbkap) (inactive)]

This came out of an IRC discussion about bug 299205:

14:28 < brendan> <brendan> bz: locking (pinning) a gc-thing should, in the
                 case of the object, always add it to the rt->gcLocksHash
                 table
14:29 < brendan> locking alas does not do that -- it first sets the lock
                 bit
14:29 < brendan> or i should say, tests it
14:29 < bz> which means what in practice?
14:29 < brendan> if it can just flip that bit, it avoids the hash table
                 update
14:29 < bz> ok....
14:29 < brendan> that means that if the object being 
14:30 < brendan> which means they may be GC'ed if also unreachable
14:30 < brendan> which leaves this object with dangling refs in its slots
                 vector
14:30 < brendan> and maybe in its private data
14:29 < brendan> it will be marked, and its kids too
14:29 < brendan> but if it's not reachable, locking that just sets the bit
                 fails to update rt->gcLocksHash, which is the *only* way
                 to reach that object
14:29 < brendan> the object won't be GC'ed
14:30 < brendan> because GCF_LOCK protects it
14:30 < brendan> but its kids won't be marked

Comment 1

[Brendan Eich [:brendan]]

I'll get this in tonight if it's safe enough.

/be

Comment 2

[Brendan Eich [:brendan]]

Well, duh.  Locking *does* always add objects to rt->gcLocksHash -- my memory
was of the bad intermediate state I perpetrated, which shaver fixed in bug 296006.

So this bug is INVALID -- sorry, my fault.  And I think the only effect that bz
saw leading to a crash was the poking rt->gcPoke'ing done by js_UnlockGCThingRT.
 Boris, holler if that leaves a mystery unsolved.

/be

Comment 3

[Boris Zbarsky [:bzbarsky]]

No, I think things are happy here...

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Verifying.