quickstart-unity: Unity editor crash caused by Firestore lock issue

Please fill in the following fields:

Unity editor version: 2019.3.7f1 Firebase Unity SDK version: 6.13.0 Source you installed the SDK (.unitypackage or Unity Package Manager): Unity Package Manager Firebase plugins in use (Auth, Database, etc.): Auth, Firestore, App Additional SDKs you are using (Facebook, AdMob, etc.): None (replicated in a clean new project) Platform you are using the Unity editor on (Mac, Windows, or Linux): Mac Platform you are targeting (iOS, Android, and/or desktop): Editor Scripting Runtime (Mono, and/or IL2CPP): Mono

Please describe the issue here:

I created a brand new project and installed the Firebase SDK via the Unity Package Manager.

I created a single button that when pressed creates a single listener on a Firestore document.

public void Test() { var store = FirebaseFirestore.DefaultInstance; var doc = store.Document("/versions/1.0/people/foo"); doc.Listen(snapshot => { Debug.Log("Got snapshot"); }); }

I run the project (play button) in the editor, click the Test button, and everything works correctly.

I then stop the project (pause button), and then start the project again (play button).

When I click on the Test button the Unity Editor crashes.

This is the relevant portion of the crash report:

Application Specific Information: dyld: in dlopen() /Applications/Unity/Hub/Editor/2019.3.7f1/Unity.app/Contents/lib/libPackages/com.google.firebase.app/Firebase/Plugins/x86_64/FirebaseCppApp-6_13_0.bundle.so abort() called terminating with uncaught exception of type firebase::firestore::util::FirestoreInternalError: FIRESTORE INTERNAL ASSERTION FAILED: third_party/firebase/ios/Releases/FirebaseFirestore/core/src/firebase/firestore/core/firestore_client.cc(168) void firebase::firestore::core::FirestoreClient::Initialize(const firebase::firestore::auth::User &, const firebase::firestore::api::Settings &): Failed to open DB: Internal: Failed to open LevelDB database at /Users/colin/Library/Application Support/firestore/__FIRAPP_DEFAULT/com-quicksteplabs-wordz/main: LevelDB error: IO error: lock /Users/colin/Library/Application Support/firestore/__FIRAPP_DEFAULT/com-quicksteplabs-wordz/main/LOCK: already held by process (expected created.ok())

So, it appears the Editor is crashing because it attempts to lock the Firestore LOCK file, but it already locked it before (presumably the first time the project ran), and now it is crashing due to an assertion failure.

Please answer the following, if applicable:

This issue was replicated in a brand new project that simply had the Firestore SDK added via the Unity Package Manager.

This happens 100% of the time.

(I’m actually very surprised that I haven’t seen anyone else report this issue. It is 100% consistent for me and has halted all of my progress integrating Firestore into my projects.)

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 4
Comments: 17 (2 by maintainers)

Links to this issue

Commits related to this issue

Make Executors have deterministic shutdown (#5547) In particular: * All tasks are guaranteed to either run to completion or not run at all; * Executors can now be destroyed from the threads t... — committed to firebase/firebase-ios-sdk by wilhuff 4 years ago
Implement safe, synchronous destruction in Firestore (#5620) Now that the Executor makes strong guarantees that tasks submitted to it will either be completely run or not start at all once destructio... — committed to firebase/firebase-ios-sdk by wilhuff 4 years ago

Most upvoted comments

As a general policy we can’t really make promises about when things will go out. There are a variety of reasons why things may be delayed that are unrelated to these specific changes.

With that said, if all goes well, this fix should be in the next release. It’s possible that might not be the case though: for example the next release might be a patch for the prior one for changes unrelated to Firestore.

wilhuff on Jun 5, 2020

Following @wilhuff 's advice, I used this as temporary workaround and Unity has stopped crashing on every run:

db = FirebaseFirestore.GetInstance(FirebaseApp.Create());   // was FirebaseApp.DefaultInstance

Hope it helps.

ijaureguialzo on May 12, 2020

Seems the lock occurs when the code is changed while in play mode and the editor does not dispose properly. I’ve been able to stop it from crashing by making sure that I stop play mode before saving any code changes. Hope this helps for the time being.

kirilogan on Apr 30, 2020

The Firestore lock issue is very clearly about Firestore failing to open its local database and the crash will be in the Firestore DLL. This sounds like a different issue.

wilhuff on Apr 17, 2020

Unfortunately, the lock is being held by a C++ object that has leaked so there’s no way to get back to it. Normally I would suggest that you could disable offline persistence in settings, but we haven’t shipped that API yet…

If you want to work around this you need to find some way to get the two instances to use different files for their storage. There are a few flavors of this:

On UNIX filesystems you also just remove the directory contents. The process will still have the file open, keeping the inode alive, but the filenames will become available for reuse. Once you exit the process the space will be reclaimed. This won’t work on Windows.
An alternative to the above is to move the directory containing the database aside (renaming the directory or similar).
An alternative that’s guaranteed to work but requires a code change is to create a new Firebase App (with a random name) for each run and create your Firestore instance from that App. The app name is part of the path Firestore uses, and a random app name will prompt the SDK to create a new database.

In all of these cases note that the files will still be open and the editor process will eventually run out of files/memory, but it will at least stop you from needing to restart every time.

wilhuff on Apr 16, 2020

The fix for this was released with the Firebase Unity SDK 6.15.1.

wilhuff on Jun 30, 2020

Right, that’s a workaround you can use for now. The fix that’s pending should make it so that an explicit shutdown/clear like this should be unnecessary.

wilhuff on Jun 5, 2020