We are not locking down our hashtables. This needs to be fixed and an total analysis done on the thread saftey of xpcom/proxy.
Summary: XPCOM/Proxy needs to be threadsafe!! → [dogfood] XPCOM/Proxy needs to be threadsafe!!
marking as dogfood to get attention. This will bit us soon. We should fix this asap.
Without a reproducible testcase, cannot put on PDT+. Putting on PDT- for now. But yes, you have our attention :-)
will never make it for m12.
*** Bug 22798 has been marked as a duplicate of this bug. ***
there is a test case for this bug attached to bug 22798 as well as lots of commentary that i'm too lazy to copy.
oops, i meant bug 21556. The word is that its a dup of this one but no one has actually marked it as a dup. Its a dependency.
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
Moving out of m13 to m14.
Hmm...I noticed you've moved it out the M14. While I may be restating the obvious, this bug completely wastes mozilla on an SMP machine. Thus I feel this is a very important bug and the number of votes for it seem to reflect that. It should be quite easy to debug (I know, I should do it myself, rather than whine) on a SMP machine. Personally I think this is required for beta and/or dogfood.
niles, bug #21556, depending on 18110, is marked PDT+. Clearing Status Whiteboard.
*** Bug 21556 has been marked as a duplicate of this bug. ***
I believe that xpcom/proxy is now relatively threadsafe. The stack crawls that I saw today on the smp machine are related to a necko bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
ok to mark Verified per dp.
Status: RESOLVED → VERIFIED
Do you know the bug number for the necko issue? I still seem to be getting crashes, although they are now MUCH less frequent, so I'd like to follow up on that one. Thanx!
You need to log in before you can comment on or make changes to this bug.