(In reply to Dragana Damjanovic [:dragana] from comment #6) > CacheIO Thread holds mRCWNLock and try to dispatch SyncRunnable on the main thread: > 45 mozilla::net::nsHttpChannel::OnCacheEntryCheck(nsICacheEntry*, nsIApplicationCache*, unsigned int*) + 2485 (XUL + 7218629) [0x107e7d5c5] 1-45 > 45 mozilla::net::nsHttpChannel::OpenCacheInputStream(nsICacheEntry*, bool, bool) + 1539 (XUL + 7225683) [0x107e7f153] 1-45 > 45 mozilla::net::CacheEntry::GetSecurityInfo(nsISupports**) + 197 (XUL + 41189653) [0x109ee3115] 1-45 > 45 NS_DeserializeObject(nsTSubstring<char> const&, nsISupports**) + 131 (XUL + 6224003) [0x107d8a883] 1-45 > 45 nsBinaryInputStream::ReadObject(bool, nsISupports**) + 274 (XUL + 5336850) [0x107cb1f12] 1-45 > 45 nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) + 44 (XUL + 5114444) [0x107c7ba4c] 1-45 > 45 nsCreateInstanceByCID::operator()(nsID const&, void**) const + 42 (XUL + 5481626) [0x107cd549a] 1-45 > 45 nsComponentManagerImpl::CreateInstance(nsID const&, nsISupports*, nsID const&, void**) + 183 (XUL + 5470679) [0x107cd29d7] 1-45 > 45 nsresult mozilla::psm::NSSConstructor<mozilla::psm::TransportSecurityInfo>(nsISupports*, nsID const&, void**) + 56 (XUL + 84060120) [0x10c7c57d8] 1-45 > 45 EnsureNSSInitializedChromeOrContent() + 583 (XUL + 21727959) [0x108c53ad7] 1-45 > 45 mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) + 156 (XUL + 5904060) [0x107d3c6bc] 1-45 > > The main Thread is waiting on the mRCWNLock. > > Kershaw, do I recall correctly that we have this SyncRunnable only because of some test? EnsureNSSInitializedChromeOrContent should always be called on the main thread. > No, I think this is a different problem and this bug could be regressed by bug 1634065.
(In reply to Dragana Damjanovic [:dragana] from comment #6) :net::nsHttpCha nnel::OnCacheEn tryCheck( nsICacheEntry* , nsIApplicationC ache*, unsigned int*) + 2485 (XUL + 7218629) [0x107e7d5c5] 1-45 :net::nsHttpCha nnel::OpenCache InputStream( nsICacheEntry* , bool, bool) + 1539 (XUL + 7225683) [0x107e7f153] 1-45 :net::CacheEntr y::GetSecurityI nfo(nsISupports **) + 197 (XUL + 41189653) [0x109ee3115] 1-45 bject(nsTSubstr ing<char> const&, nsISupports**) + 131 (XUL + 6224003) [0x107d8a883] 1-45 ream::ReadObjec t(bool, nsISupports**) + 274 (XUL + 5336850) [0x107cb1f12] 1-45 base::assign_ from_helper( nsCOMPtr_ helper const&, nsID const&) + 44 (XUL + 5114444) [0x107c7ba4c] 1-45 eByCID: :operator( )(nsID const&, void**) const + 42 (XUL + 5481626) [0x107cd549a] 1-45 gerImpl: :CreateInstance (nsID const&, nsISupports*, nsID const&, void**) + 183 (XUL + 5470679) [0x107cd29d7] 1-45 :psm::NSSConstr uctor<mozilla: :psm::Transport SecurityInfo> (nsISupports* , nsID const&, void**) + 56 (XUL + 84060120) [0x10c7c57d8] 1-45 lizedChromeOrCo ntent() + 583 (XUL + 21727959) [0x108c53ad7] 1-45 :SyncRunnable: :DispatchToThre ad(nsIEventTarg et*, bool) + 156 (XUL + 5904060) [0x107d3c6bc] 1-45 lizedChromeOrCo ntent should always be called on the main thread.
> CacheIO Thread holds mRCWNLock and try to dispatch SyncRunnable on the main thread:
> 45 mozilla:
> 45 mozilla:
> 45 mozilla:
> 45 NS_DeserializeO
> 45 nsBinaryInputSt
> 45 nsCOMPtr_
> 45 nsCreateInstanc
> 45 nsComponentMana
> 45 nsresult mozilla:
> 45 EnsureNSSInitia
> 45 mozilla:
>
> The main Thread is waiting on the mRCWNLock.
>
> Kershaw, do I recall correctly that we have this SyncRunnable only because of some test? EnsureNSSInitia
>
No, I think this is a different problem and this bug could be regressed by bug 1634065.