418561 - MakeArraySlow() does thread-unsafe set of JSClass slot.

Status: RESOLVED DUPLICATE of bug 419537

(Core :: JavaScript Engine, defect)

Description

[Johnny Stenback (:jst)]

http://lxr.mozilla.org/mozilla/source/js/src/jsarray.c#1081

Link pretty much says it all, multi-instruction set of obj->fslots[JSSLOT_CLASS], a racing thread could end up getting a null class, which is supposed to be impossible.

Shaver gets this one per discussion on irc.

Comment 1

[Brian Crowder]

Attachment: coherent class flags at all times

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 304401 [details] [diff] [review]
coherent class flags at all times

r=shaver

Comment 3

[Brendan Eich [:brendan]]

Comment on attachment 304401 [details] [diff] [review]
coherent class flags at all times

This still isn't thread-safe -- you want the ensemble change to obj to be atomic.

/be

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Not sure how to make that whole transition atomic WRT racing STOBJ_GET_CLASS, off-hand, but I'll sleep on it some more.  We definitely need to sprinkle some threadsafety dust on arrays, which will include locking around the bulk of MakeArraySlow, so maybe it's not worth fixing this independently?  Even with that, though, STOBJ_GET_CLASS explicitly doesn't participate in the locking protocol, so it will still race.

We need the atomic update of JSSLOT_CLASS to keep STOBJ_GET_CLASS from seeing NULL, but any more involved use of the clasp will require that the caller do the right thing with title locking...

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Moving bugs that aren't beta 4 blockers to target final release.

Comment 6

[Damon Sicore (:damons)]

taking this off the blocking the list.  There are bigger bugs tracking the general problem.

Comment 7

[Brian Crowder]

Going to just dupe this forward to bug 419537, which is the meta shavarray thread-safety bug.