Closed Bug 1033493 Opened 11 years ago Closed 9 years ago

Hangs/long loops on nsUrlClassifierDBServiceWorker thread, pages and its subresources take ages to load

Categories

(Toolkit :: Safe Browsing, defect)

Product:
Toolkit
Component:
Safe Browsing
Version:
31 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1164518

People

(Reporter: mayhemer, Unassigned)

Details

Crash Data

Nightly, 83c09fe3a658, BuildID=20140701030202, Win8. Started to manifest on visit of https://www.conrad.cz/kosik/ (with having something in the basket of course) and pressing the 'Pokračovat' button and then the browsr back button. Not sure however these are reliable STR. Symptoms: - page loading slowed *rapidly* down, appeared like an ISP problem for me first - I tried to restart Firefox => shutdown hang, with one background thread spinning (some 75% of one of the cores): Main thread: xul.dll!nsThread::Shutdown() Line 598 + 0xa bytes C++ xul.dll!nsUrlClassifierDBService::Shutdown() Line 1547 C++ xul.dll!nsUrlClassifierDBService::Observe(nsISupports * aSubject, const char * aTopic, const wchar_t * aData) Line 1502 C++ xul.dll!nsObserverList::NotifyObservers(nsISupports * aSubject, const char * aTopic, const wchar_t * someData) Line 96 + 0x14 bytes C++ xul.dll!nsObserverService::NotifyObservers(nsISupports * aSubject, const char * aTopic, const wchar_t * someData) Line 303 + 0xf bytes C++ xul.dll!nsXREDirProvider::DoShutdown() Line 871 C++ xul.dll!ScopedXPCOMStartup::~ScopedXPCOMStartup() Line 1197 C++ xul.dll!ScopedXPCOMStartup::`scalar deleting destructor'() + 0x8 bytes C++ xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData) Line 4114 C++ xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData, unsigned int aFlags) Line 4298 + 0xd bytes C++ Classifier thread: xul.dll!mozilla::safebrowsing::AddPrefix::Compare<mozilla::safebrowsing::AddPrefix>(const mozilla::safebrowsing::AddPrefix & other) Line 153 + 0x4 bytes C++ xul.dll!mozilla::safebrowsing::EntryCompare<mozilla::safebrowsing::AddPrefix>::Compare(const void * e1, const void * e2) Line 259 C++ msvcr100.dll!shortsort(char * lo, char * hi, unsigned int width, int (const void *, const void *)* comp) Line 355 + 0x5 bytes C msvcr100.dll!qsort(void * base, unsigned int num, unsigned int width, int (const void *, const void *)* comp) Line 136 + 0xd bytes C xul.dll!mozilla::safebrowsing::EntrySort<mozilla::safebrowsing::AddPrefix,nsTArrayFallibleAllocator>(nsTArray_Impl<mozilla::safebrowsing::AddPrefix,nsTArrayFallibleAllocator> & aArray) Line 272 + 0x15 bytes C++ xul.dll!mozilla::safebrowsing::Merge<mozilla::safebrowsing::AddPrefix>(mozilla::safebrowsing::ChunkSet * aStoreChunks, FallibleTArray<mozilla::safebrowsing::AddPrefix> * aStorePrefixes, mozilla::safebrowsing::ChunkSet & aUpdateChunks, FallibleTArray<mozilla::safebrowsing::AddPrefix> & aUpdatePrefixes, bool aAllowMerging) Line 481 C++ xul.dll!mozilla::safebrowsing::HashStore::ApplyUpdate(mozilla::safebrowsing::TableUpdate & update) Line 497 + 0x14 bytes C++ xul.dll!mozilla::safebrowsing::Classifier::ApplyTableUpdates(nsTArray<mozilla::safebrowsing::TableUpdate *> * aUpdates, const nsACString_internal & aTable) Line 631 C++ xul.dll!mozilla::safebrowsing::Classifier::ApplyUpdates(nsTArray<mozilla::safebrowsing::TableUpdate *> * aUpdates) Line 329 C++ xul.dll!nsUrlClassifierDBServiceWorker::CacheCompletions(nsTArray<mozilla::safebrowsing::CacheResult> * results) Line 709 C++ xul.dll!UrlClassifierDBServiceWorkerProxy::CacheCompletionsRunnable::Run() Line 166 C++ xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 766 + 0x8 bytes C++ xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 284 + 0x1f bytes C++ xul.dll!mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate * aDelegate) Line 337 + 0xa bytes C++ xul.dll!MessageLoop::RunHandler() Line 223 C++ xul.dll!MessageLoop::Run() Line 197 C++ xul.dll!nsThread::ThreadFunc(void * aArg) Line 355 C++ nss3.dll!_PR_NativeRunThread(void * arg) Line 419 C msvcr100.dll!_getptd_noexit() Line 498 + 0x7 bytes C msvcr100.dll!_callthreadstartex() Line 314 + 0x6 bytes C msvcr100.dll!_threadstartex(void * ptd) Line 292 + 0x5 bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!__RtlUserThreadStart() + 0x4e bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1c bytes I attached a debugger, paused (symbols loaded, no sources) and tried to put breakpoints up to NS_ProcessNextEvent. It well popped up to that frame on re-run and then started to loop (process messages) again, like the code would be posting to the classifier thread on and on other events or there already where a huge number scheduled before and each was taking enormous amount of time to process. Please be aware that (now I realize) I didn't check the classifier thread was the one calling NS_ProcessNextEvent on and on, so it could well be main thread, sorry :/ Second problem: After kill and restart, I went to the same page (session store) and tried to complete my online purchase once more. And it started again, same symptoms. Another debugging sessions shows one stack: ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_ZwSetInformationFile@20() + 0xa bytes KernelBase.dll!MoveFileWithProgressTransactedW() + 0x1d2 bytes KernelBase.dll!_MoveFileExW@12() + 0x18 bytes xul.dll!nsLocalFile::CopySingleFile(nsIFile * aSourceFile, nsIFile * aDestParent, const nsAString_internal & aNewName, unsigned int aOptions) Line 1910 C++ xul.dll!nsLocalFile::CopyMove(nsIFile * aParentDir, const nsAString_internal & aNewName, unsigned int aOptions) Line 2030 C++ xul.dll!nsLocalFile::MoveTo(nsIFile * aNewParentDir, const nsAString_internal & aNewName) Line 2205 C++ xul.dll!nsAtomicFileOutputStream::Finish() Line 944 + 0x11 bytes C++ xul.dll!nsSafeFileOutputStream::Finish() Line 984 + 0x6 bytes C++ xul.dll!nsCheckSummedOutputStream::Finish() Line 47 + 0x6 bytes C++ xul.dll!mozilla::safebrowsing::HashStore::WriteFile() Line 857 + 0x9 bytes C++ xul.dll!mozilla::safebrowsing::Classifier::ApplyTableUpdates(nsTArray<mozilla::safebrowsing::TableUpdate *> * aUpdates, const nsACString_internal & aTable) Line 679 C++ xul.dll!mozilla::safebrowsing::Classifier::ApplyUpdates(nsTArray<mozilla::safebrowsing::TableUpdate *> * aUpdates) Line 329 C++ xul.dll!nsUrlClassifierDBServiceWorker::CacheCompletions(nsTArray<mozilla::safebrowsing::CacheResult> * results) Line 709 C++ xul.dll!UrlClassifierDBServiceWorkerProxy::CacheCompletionsRunnable::Run() Line 166 C++ xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 766 + 0x8 bytes C++ xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 284 + 0x1f bytes C++ xul.dll!mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate * aDelegate) Line 337 + 0xa bytes C++ xul.dll!MessageLoop::RunHandler() Line 223 C++ xul.dll!MessageLoop::Run() Line 197 C++ xul.dll!nsThread::ThreadFunc(void * aArg) Line 355 C++ nss3.dll!_PR_NativeRunThread(void * arg) Line 419 C nss3.dll!pr_root(void * arg) Line 90 + 0xc bytes C msvcr100.dll!_callthreadstartex() Line 314 + 0x6 bytes C msvcr100.dll!_threadstartex(void * ptd) Line 292 + 0x5 bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!__RtlUserThreadStart() + 0x4e bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1c bytes After a while (actually just few seconds) it stopped and I could browse normally. Now I cannot reproduce, but I'm OK to try again.
Crash Signature: shutdownhang | __psynch_cvwait
Component: DOM: Security → Safe Browsing
Product: Core → Toolkit
This looks like another dupe of bug 1164518. Francois, that bug is starting to look very serious and urgent. I wonder if we risk having these more now that Google is deploying v4 which is less likely to suffer from these malware vs propular site collisions.
Flags: needinfo?(gpascutto)
Duping based on "page takes very long to load" and the stack being in a complete DB update caused by caching a completion.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.