52718 - componentManager is not reentrant

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[aaronb]

An attempt to create a component instance outside the main thread raises the 
assertion:

###!!! ASSERTION: nsComponentManagerImpl not thread-safe: 'owningThread ==
NS_CurrentThread()', file c:\mozilla_source\mozilla\xpcom\base\nsDebug.cpp,
line 490

Comment 1

[Jon Smirl]

I'm tripping this too. My code needs to create JS components from other than 
the main thread. These component instances are only used by the thread that 
creates them. Component manager needs to be thread safe. I don't see that there 
is any real way to avoid this.

Switching to NS_IMPL_THREADSAFE_ISUPPORTS() will make the assert go away but 
the code needs to be checked for thread safety.

Comment 2

[Jon Smirl]

Attachment: Stack trace to the assert

Comment 3

[Jon Smirl]

I hit the asert at:
nsComponentManager.cpp lines 403, 513
nsRegistry.cpp lines 341, 1946

Comment 4

[Jon Smirl]

also nsCategoryManager.cpp line 152

Comment 5

[Jon Smirl]

also mozJSComponentLoader.cpp line 241

Comment 6

[Ray Whitmer]

It seems clear from this assertion that component manager was not designed to be 
thread safe.  The cost of making it usable outside the primary thread needs to 
be weighed for the future.

Comment 7

[Jon Smirl]

Thread safe component creation is critical for a server environment. I might as 
well make my web server single threaded if I have to marshal every create 
instance call off to the main thread. This totally prohibits building a 
scalable server based on XPCOM.

I don't this this is a bad as it looks. There are comments all over the 
component loader and registry code about threading issues. Obviously someone 
has already looked into this. The asserts may simple be a bogus side effect of 
changing NS_IMPL_ISUPPORTS.

Could the authors of these components verify if the problem is simply not 
having changed NS_IMPL_ISUPPORTS to NS_IMPL_THREADSAFE_ISUPPORTS where needed, 
or if these components really aren't threadsafe?

Comment 8

[Warren Harris]

Assigning rest of xpcom stuff to myself (from Ray).

Comment 9

[Jon Smirl]

I broke this bug down into four more acurate ones:

54633  nor P3 All [e-mail] UNCO  nsCategoryManagerFactory is not 
threadsafe  
54635  nor P3 All [e-mail] UNCO  nsRegistryFactory is not threadsafe  
54636  nor P3 All [e-mail] UNCO  nsRegistry is not threadsafe  
54638  nor P3 All [e-mail] UNCO  nsComponentManagerImpl is not 
threadsafe  
54639  nor P3 Oth [e-mail] UNCO  nsCategoryManager is not threadsafe  

You can close this one when the other four are opened. JBand has already fixed 
mozComponentLoader

Comment 10

[Asa Dotzler [:asa]]

reasigning warren bugs to default component owners.

Comment 11

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 12

[Doug Turner (:dougt)]

moving out based on my workload.  Yell, if you have a problem.

Comment 13

[Doug Turner (:dougt)]

This is and has been fix for a while.  You should have no problem creating a
component via the component manager from a seperate thread.  Most of the
problems were fixed when 48888 landed.  Marking fixed.