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.
Created attachment 304401 [details] [diff] [review] coherent class flags at all times
Assignee: shaver → crowder
Status: NEW → ASSIGNED
Attachment #304401 - Flags: review?(brendan)
Comment on attachment 304401 [details] [diff] [review] coherent class flags at all times r=shaver
Attachment #304401 - Flags: approval1.9? → approval1.9+
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
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...
Moving bugs that aren't beta 4 blockers to target final release.
Target Milestone: mozilla1.9beta4 → mozilla1.9
taking this off the blocking the list. There are bigger bugs tracking the general problem.
Going to just dupe this forward to bug 419537, which is the meta shavarray thread-safety bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 419537
You need to log in before you can comment on or make changes to this bug.