This bug was filed from the Socorro interface and is report bp-d0c71cf6-4f3c-48b1-9f5a-1b4c60170524. ============================================================= Crashing Thread (50) Frame Module Signature Source 0 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::GetFileForFileInfo dom/indexedDB/ActorsParent.cpp:10230 1 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::DatabaseOperationBase::GetStructuredCloneReadInfoFromExternalBlob dom/indexedDB/ActorsParent.cpp:19800 2 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::DatabaseOperationBase::GetStructuredCloneReadInfoFromSource<mozIStorageStatement> dom/indexedDB/ActorsParent.cpp:19677 3 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::ObjectStoreGetRequestOp::DoDatabaseWork dom/indexedDB/ActorsParent.cpp:26809 4 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::TransactionDatabaseOperationBase::RunOnConnectionThread dom/indexedDB/ActorsParent.cpp:23584 5 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::TransactionDatabaseOperationBase::Run dom/indexedDB/ActorsParent.cpp:23759 6 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1264 7 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:389 8 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::ConnectionPool::ThreadRunnable::Run dom/indexedDB/ActorsParent.cpp:13475 9 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1264 10 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:389 11 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:338 12 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:231 13 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:211 14 xul.dll nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:495 15 nss3.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 16 nss3.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:95 17 ucrtbase.dll _o__CIpow 18 kernel32.dll BaseThreadInitThunk 19 ntdll.dll __RtlUserThreadStart 20 ntdll.dll _RtlUserThreadStart this crash signature is showing up in a low volume starting in firefox 52 and subsequent builds from users on windows. many user comments talk about trying to load a game at the time of the crash - one url that got specifically mentioned was http://www.kongregate.com/games/synapticon/spellstone, other games apparently included candycrush & battlehand...
Jan, Bevis: any thoughts on what could be happening here?
I get stuck by bug 1367497 and hope to be available next week to look into this. Keep NI flag on me.
According to the report in comment 0, the crash was happened while de-referencing FileManager from a FileInfo instance: http://searchfox.org/mozilla-central/rev/1a0d9545b9805f50a70de703a3c04fc0d22e3839/dom/indexedDB/ActorsParent.cpp#10256 After further review of both ObjectStoreAddOrPutRequestOp and ObjectStoreGetRequestOp to understand the flow of how a StructureClone object to be stored as a external file, I didn't any reason why the FileManager would become invalid. The instance of FileManager should always be valid after an IDBOpenRequest to an IDBDatabase is done successfully: http://searchfox.org/mozilla-central/rev/1a0d9545b9805f50a70de703a3c04fc0d22e3839/dom/indexedDB/ActorsParent.cpp#21903 Otherwise, it's impossible to get and IDBObjectStore for retrieving any objects from the store in advance. The only thing that is suspicious from the call stack is that the same FileManager was accessed successfully at GetStructuredCloneReadInfoFromExternalBlob() when running into DeserializeStructuredCloneFiles(): http://searchfox.org/mozilla-central/source/dom/indexedDB/ActorsParent.cpp#9868 However, it was crashed few lines later at GetStructuredCloneReadInfoFromExternalBlob() when running into GetFileForFileInfo(). I've also tried to play the game in http://www.kongregate.com/games/synapticon/spellstone on my windows machine, but I have no luck to reproduce this problem locally. :|
GetStructuredCloneReadInfoFromExternalBlob() seems to be always on the stack, so it's a big structure clone stored outside database. Given this is a game it makes sense it tries to get something big. However, it doesn't makes sense why filemanager would be null here, FileInfo holds a strong reference to FileManager and it's never released until FileInfo is destroyed.
This is an assigned P1 bug without activity in two weeks. If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword. Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.
Very low volume crash, so far no crashes on 57...