124980 - Don't call getservice on nonprimary thread.

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P1)

Description

[timeless]

w32 cvs depend build this evening.

###!!! ASSERTION: nsNativeComponentLoader not thread-safe: 'owningThread == 
NS_CurrentThread()', file f:\build\mozilla\xpcom\glue\nsDebug.cpp, line 528

NTDLL! 77fa018c()
nsDebug::Assertion(const char * 0x1012996c, const char * 0x10134630, const char 
* 0x10134608, int 528) line 291 + 13 bytes
NS_CheckThreadSafe(void * 0x00442510, const char * 0x1012996c) line 528 + 34 
bytes
nsNativeComponentLoader::AddRef(nsNativeComponentLoader * const 0x00446340) 
line 90 + 60 bytes
nsComponentManagerImpl::GetLoaderForType(int 0, nsIComponentLoader * * 
0x0311f88c) line 2724
nsFactoryEntry::GetFactory(nsIFactory * * 0x0311f8d0, nsComponentManagerImpl * 
0x004465b0) line 322 + 39 bytes
nsComponentManagerImpl::FindFactory(const char * 0x0238ad08, nsIFactory * * 
0x0311f8d0) line 1624
nsComponentManagerImpl::CreateInstanceByContractID(nsComponentManagerImpl * 
const 0x004465b0, const char * 0x0238ad08, nsISupports * 0x00000000, const nsID 
& {...}, void * * 0x0311f920) line 1853 + 16 bytes
nsComponentManagerImpl::GetServiceByContractID(nsComponentManagerImpl * const 
0x004465b4, const char * 0x0238ad08, const nsID & {...}, void * * 0x0311f9ac) 
line 2247 + 50 bytes
nsServiceManager::GetService(const char * 0x0238ad08, const nsID & {...}, 
nsISupports * * 0x0311f9ac, nsIShutdownListener * 0x00000000) line 121
getNSSDialogs(void * * 0x0311fb14, const nsID & {...}) line 1562 + 45 bytes
nsContinueDespiteCertError(nsNSSSocketInfo * 0x067017e0, PRFileDesc * 
0x06706060, int -8156, nsNSSCertificate * 0x06714030) line 1243 + 15 bytes
nsNSSBadCertHandler(void * 0x067017e0, PRFileDesc * 0x06706060) line 2120 + 21 
bytes
ssl3_HandleCertificate(sslSocketStr * 0x067015d0, unsigned char * 0x05c3fdf3, 
unsigned int 0) line 6560 + 25 bytes
ssl3_HandleHandshakeMessage(sslSocketStr * 0x067015d0, unsigned char * 
0x05c3fb6c, unsigned int 647) line 7150 + 17 bytes
ssl3_HandleHandshake(sslSocketStr * 0x067015d0, sslBufferStr * 0x067060f4) line 
7266 + 25 bytes
ssl3_HandleRecord(sslSocketStr * 0x067015d0, SSL3Ciphertext * 0x0311fcb8, 
sslBufferStr * 0x067060f4) line 7531 + 13 bytes
ssl3_GatherCompleteHandshake(sslSocketStr * 0x067015d0, int 0) line 204 + 20 
bytes
ssl_GatherRecord1stHandshake(sslSocketStr * 0x067015d0) line 1301 + 11 bytes
ssl_Do1stHandshake(sslSocketStr * 0x067015d0) line 156 + 10 bytes
ssl_SecureRecv(sslSocketStr * 0x067015d0, unsigned char * 0x05c3f330, int 2048, 
int 0) line 1038 + 9 bytes
ssl_SecureRead(sslSocketStr * 0x067015d0, unsigned char * 0x05c3f330, int 2048) 
line 1057 + 19 bytes
ssl_Read(PRFileDesc * 0x06706060, void * 0x05c3f330, int 2048) line 1232 + 21 
bytes
nsSSLIOLayerRead(PRFileDesc * 0x0481ffd0, void * 0x05c3f330, int 2048) line 969 
+ 26 bytes
PR_Read(PRFileDesc * 0x0481ffd0, void * 0x05c3f330, int 2048) line 136 + 20 
bytes
nsSocketIS::Read(nsSocketIS * const 0x0670bc60, char * 0x05c3f330, unsigned int 
2048, unsigned int * 0x0311fde0) line 2426 + 21 bytes
nsReadFromInputStream(nsIOutputStream * 0x066f6e34, void * 0x0670bc60, char * 
0x05c3f330, unsigned int 0, unsigned int 2048, unsigned int * 0x0311fde0) line 
848
nsPipe::nsPipeOutputStream::WriteSegments(nsPipe::nsPipeOutputStream * const 
0x066f6e34, unsigned int (nsIOutputStream *, void *, char *, unsigned int, 
unsigned int, unsigned int *)* 0x10065880 nsReadFromInputStream(nsIOutputStream 
*, void *, char *, unsigned int, unsigned int, unsigned int *), void * 
0x0670bc60, unsigned int 8192, unsigned int * 0x0311fe74) line 721 + 29 bytes
nsPipe::nsPipeOutputStream::WriteFrom(nsPipe::nsPipeOutputStream * const 
0x066f6e34, nsIInputStream * 0x0670bc60, unsigned int 8192, unsigned int * 
0x0311fe74) line 856
nsStreamListenerProxy::OnDataAvailable(nsStreamListenerProxy * const 
0x066f0f10, nsIRequest * 0x066f60b0, nsISupports * 0x00000000, nsIInputStream * 
0x0670bc60, unsigned int 0, unsigned int 8192) line 303 + 38 bytes
nsSocketReadRequest::OnRead() line 2871 + 57 bytes
nsSocketTransport::doReadWrite(short 1) line 1077 + 14 bytes
nsSocketTransport::Process(short 1) line 541 + 13 bytes
nsSocketTransportService::Run(nsSocketTransportService * const 0x029c5bf4) line 
516 + 13 bytes
nsThread::Main(void * 0x029c55c0) line 120 + 26 bytes
_PR_NativeRunThread(void * 0x029c53a0) line 413 + 13 bytes
_threadstartex(void * 0x029c51f0) line 212 + 13 bytes
KERNEL32! 77e8758a()

getNSSDialogs(void * * 0x0311fb14, const nsID & {...}) line 1562 + 45 bytes
  rv = nsServiceManager::GetService(kNSSDialogsContractId, 
                                    NS_GET_IID(nsINSSDialogs),
                                    getter_AddRefs(result));
+	kNSSDialogsContractId	0x0238ad08 "@mozilla.org/nsNSSDialogs;1"

Comment 1

[Wan-Teh Chang]

Changed product to PSM.

Comment 2

[Stephane Saux]

The question is whether you can have security dialogs without calling getService
on  the nonprimary thread.

kai.

Comment 3

[Kai Engert (:KaiE:)]

Timeless, can you please explain, why it is not allowed to call getservice on
the nonprimary thread?
Or do you know, who could explain it, and whether there is a workaround?
Is it required to pre-load all components, that might become accessed from a
non-primary thread?

Comment 4

[Kai Engert (:KaiE:)]

Doug, can you give us more insight on this issue?

The question is: Is it correct, we are not allowed to call getservice from a
non-primary thread?

If we are not allowed, what should we do instead?

Comment 5

[Doug Turner (:dougt)]

the component loaders are not thread safe.  I have a bug on this problem. 
Reassigning to me.

Comment 6

[John Unruh]

nsbeta1

Comment 7

[Gagan]

[adt needinfo] user impact? how bad? workaround? what is the meaning of life? etc...

Comment 8

[Doug Turner (:dougt)]

How bad - race condition which could led to unpredictable results including crashes.

Work around is to ensure that the service has been created on the main thread
prior to requesting it from other threads.  Not nice.  There is NO workaround
for CI from a non main thread.  

This can not be solved (easily) until 48888 lands.  In fact, when the patch does
land, this bug will become fixed. :-)

Comment 9

[Gagan]

with such a vivid and scary description of possible problems who can refuse a
plus? that would be me. now go forth and save the world!

Comment 10

[Doug Turner (:dougt)]

This "should" be fixed.  I landed this fix on 2002/04/15 as part of bug 98755.

Comment 11

[John Unruh]

Verified per dougt's comment.