Crash in mozilla::dom::indexedDB::`anonymous namespace''::GetFileForFileInfo

Assigned to



DOM: IndexedDB
6 months ago
2 months ago


(Reporter: philipp, Assigned: janv)


({crash, regression, stale-bug})

52 Branch
crash, regression, stale-bug

Firefox Tracking Flags

(firefox-esr52 affected, firefox53 wontfix, firefox54 wontfix, firefox55 wontfix, firefox56 wontfix, firefox57 ?)


(crash signature)



6 months ago
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/
13 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/
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, other games apparently included candycrush & battlehand...
Jan, Bevis: any thoughts on what could be happening here?
Flags: needinfo?(jvarga)
Flags: needinfo?(btseng)
I get stuck by bug 1367497 and hope to be available next week to look into this.
Keep NI flag on me.
status-firefox53: affected → wontfix
According to the report in comment 0, the crash was happened while de-referencing FileManager from a FileInfo instance:

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:
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():
However, it was crashed few lines later at GetStructuredCloneReadInfoFromExternalBlob() when running into GetFileForFileInfo().

I've also tried to play the game in on my windows machine, but I have no luck to reproduce this problem locally. :|
Flags: needinfo?(btseng)

Comment 4

5 months ago
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.
Assignee: nobody → jvarga
Flags: needinfo?(jvarga)
Priority: -- → P1
status-firefox54: affected → wontfix
status-firefox55: ? → affected
status-firefox56: --- → ?
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.
Keywords: stale-bug
Very low volume crash, so far no crashes on 57...
status-firefox55: affected → wontfix
status-firefox56: ? → wontfix
status-firefox57: --- → ?
Per comment 3 (the difficulty of reproducing this) and comment 6, moving this to P3.
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.