I posted a patch to 98755 which should address the threadsafety problems in nsNativeComponentLoader.
Doug Turner wrote: > A couple of things to note: > > See bugs 98755 and more generally 101976 > for known threadsafety problems in xpcom. > > Also, the mime assertion that you are > seeing should be fixed in the trunk. > When the nsFileIO class no longer eagerly > searches for mime types. > > Regards, > > Doug Turner > > > Paul Rouleau wrote: > >> I added the following two lines of code after my call to >> NS_InitEmbedding( ).... >> >> nsCOMPtr<nsIMIMEService> mMimeService; >> mMimeService = do_GetService(NS_MIMESERVICE_CONTRACTID); >> >> >> .... and that seemed to do the trick.... No more asserts. >> >> Obviously, this is a hack, but I'll leave it in and check newer >> releases and see if >> it will still be necessary. >> >> Thanks John for your help. >> >> - Paul >> >> >> >> Paul Rouleau wrote: >> >> >>> Ok, I'll try it.... >>> >>> .....but, I'm not exactly sure what component I should create >>> (nsFileTransport, >>> nsFileIO, nsTransportService or nsCOMPtr<nsIMIMEService> (see >>> callstack below). >>> >>> Or, is this something that initiated from outside this thread. If >>> that is the >>> case, should I be trying to create something else? >>> >>> Nonetheless, I'll try each class in the callstack and see what happens. >>> >>> I'm sorry if I sound like a newbee (....although, I am...). >>> >>> Thanks for your help, >>> - Paul >>> >>> John Bandhauer wrote: >>> >>> >>>> I bet the difference is that (for whatever reason) in your >>>> embedding the *first* time an instance of that particular >>>> component is created happens on a thread other than the main >>>> thread, while in other embeddings the first instance is created >>>> on the main thread at some time before this. >>>> >>>> The component loader is only called to get the factory the first >>>> time the factory is needed. On subsequent calls to create an >>>> instance (on whatever thread) the component manager will just use >>>> its cached factory and will not call the component loader at all. >>>> >>>> The lack of full free threading access to the component loader is >>>> very ugly and ought to be fixed. >>>> >>>> I hate even saying this, but... As a stupid workaround you might >>>> try creating and releasing an instance of that particular >>>> component on your main thread right after xpcom init and before >>>> any other threads start using xpcom. >>>> >>>> John. >>>> >>>> Paul Rouleau wrote: >>>> >>>>> hmmm.. That would explain why I'm getting the assert, but I don't >>>>> understand how this is invoked, (and why it doesn't happen to >>>>> mfcembed). >>>>> >>>>> Below is my callstack..... >>>>> >>>>> NTDLL! 77f7629c() >>>>> nsDebug::Assertion() line 290 + 13 bytes >>>>> NS_CheckThreadSafe() line 528 + 34 bytes >>>>> nsNativeComponentLoader::AddRef() line 90 + 54 bytes >>>>> nsComponentManagerImpl::GetLoaderForType() line 2536 >>>>> nsFactoryEntry::GetFactory() line 328 + 39 bytes >>>>> nsComponentManagerImpl::FindFactory() line 1437 >>>>> nsComponentManagerImpl::CreateInstanceByContractID() line 1666 + 16 >>>>> bytes >>>>> nsComponentManagerImpl::GetServiceByContractID() line 2059 + 50 >>>>> bytes >>>>> nsGetServiceByContractID::operator()() line 246 + 38 bytes >>>>> nsCOMPtr<nsIMIMEService>::assign_from_helper() line 972 + 18 bytes >>>>> nsCOMPtr<nsIMIMEService>::operator=() line 604 >>>>> nsFileTransportService::GetCachedMimeService() line 119 + 31 bytes >>>>> nsFileIO::Open() line 218 + 8 bytes >>>>> nsFileTransport::Process() line 670 + 58 bytes >>>>> nsFileTransport::Run() line 638 >>>>> nsThreadPoolRunnable::Run() line 904 + 12 bytes >>>>> nsThread::Main() line 120 + 26 bytes >>>>> _PR_NativeRunThread() line 413 + 13 bytes >>>>> MSVCRTD! 0025bf53() >>>>> KERNEL32! 77f04ee8() >>>>> >>>>> It looks like this is getting triggered by a call to nsFileIO with a >>>>> file name that exists in the cache. >>>>> >>>>> >>>>> I do not explicitly call this thread to do anything. I believe it is >>>>> triggered within nsIWebNavigation::LoadURL. >>>>> >>>>> I'm guessing that either I'm not compiling my program correctly (wrong >>>>> compile switch or missing #define), or my mozilla configuration is not >>>>> consistant with that of mfcembed. >>>>> >>>>> Any ideas? >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>> >>>>> David Bradley wrote: >>>>> >>>>> Paul Rouleau wrote: >>>>> >>>>> > What does this assertion mean? >>>>> >>>>> It means that you are invoking a method on the component loader >>>>> from a >>>>> thread different than the one that created it. Which exposes it to >>>>> potential threading problems. >>>>> >>>> >> > >
