Repository navigation
Using a transaction in a session makes unity editor non responsive when attempting to start next session #783
Description
Activity
Given the nature of this issue, I wouldn't be surprised to see this occurring. On a quick inspection, I can't easily reproduce this.
I modified the test app like this:
private IEnumerator WriteDoc(DocumentReference doc, IDictionary<string, object> data) { var setTask = FirebaseFirestore.DefaultInstance.RunTransactionAsync(async transaction => { transaction.Set(doc, data); return true; }); // Task setTask = doc.SetAsync(data);and tried to capture the issue by rapidly pressing cmd+p after clicking the write doc button.
Since you report this as a 100% repro, if you could get us a good patch for the testapp that gives equivalent reproduction rate - we'll be able to quickly triage this and start looking at a fix (just reply in here with some code to update quickly).
I've actually been actively investigating this issue today and yesterday. It may or may not be related to #757, which is the issue I was trying to investigate. In any case, I'll take ownership of this ticket since there is definitely a bug. My hypothesis at the moment is that the shutdown logic for
FirebaseFirestoreis freeing a C++ object that is being used in the transaction callback. I'll update this issue when I have some concrete findings.Do you guys need a repro project or were you able to reproduce it your self?
I am able to reproduce so no repro project is needed. However, could you post (e.g. as a gist or attachment) the Unity Editor logs after the crash? That way I can confirm that it is the same crash that I'm investigating. On MacOS, the logs can be found at
~/Library/Logs/Unity/Editor.log.Update: I'm fairly certain that I found the root cause; however, I'm not sure how to fix it. Basically, a
ThreadAbortExceptionis propagating from C# into C++.When the "stop" button is pressed it causes the thread executing the transaction to throw a ThreadAbortException. Normally, we could just wrap the code in question in a try/catch block and suppress the exception, preventing it from leaking into the C++ code from which we were invoked. The problem is that ThreadAbortException is "special", in that it can be caught, but it will automatically be raised again at the end of the catch block. This automatic re-throwing precludes us from suppressing and thus allowing it to leak back into C++ which causes the crash. Thread.ResetAbort() is documented to stop the ThreadAbortException from propagating, but in my testing it had no effects and did not fix the crash.
I'm continuing to investigate but I have no solution nor a workaround at this point.
https://docs.microsoft.com/en-us/dotnet/api/system.threading.threadabortexception
Update: The hypothesis that
ThreadAbortExceptionis causing the crash turned out to be correct, and the root cause was not related to #757. I have implemented a fix for this issue and it is in code review. The fix should be included in the next release but I cannot make any commitments as to the date of that release. For now, the only workaround I can think of is to wait for all transactions to complete prior to restarting your app in the Unity Editor. I realize that this is suboptimal, possibly even impossible depending on how your app is implemented, and I sincerely apologize for the inconvenience.Update: I don't have much of an update but wanted to reassure anyone watching this issue that a fix is coming and is in the final stages of code review. It's been an incredibly complex fix, far beyond the scope of what I had originally envisioned. The workaround of avoiding re-starting your app in the Unity Editor while one or more transactions are in progress is still valid.
- Hi Denver, I got another case with the exact same symptoms as the transaction issue. It occurs when I try to use a document listener like so: DocumentReference documentReference = _firestoreClient.Db.Document(DocumentPath); _listenerRegistration =documentReference.Listen(Callback); It happens even if I try to stop the listener on Quit: _listenerRegistration.Stop(); _listenerRegistration = null; Maybe your fix resolves this issue as well?…On Tue, Oct 27, 2020 at 8:22 PM Denver Coneybeare ***@***.***> wrote: Update: I don't have much of an update but wanted to reassure anyone watching this issue that a fix is coming and is in the final stages of code review. It's been an incredibly complex fix, far beyond the scope of what I had originally envisioned. The workaround of avoiding re-starting your app in the Unity Editor while one or more transactions are in progress is still valid. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#783 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARBNC7DI3KKI22OQVQCX773SM4MVRANCNFSM4RRSJ2LA> .
Update: The fix for this issue has been submitted (cl/342923297 for Googlers). It should be included in the next release of the Unity SDK. Since there is no further work to do from our end I'm going to close this ticket; however, if this issue persists after the next release please feel free to re-open this issue. In the meantime, the workaround of avoiding re-starting your app in the Unity Editor while one or more transactions are in progress is still valid.
FYI The Firebase Unity SDK v7.0.0 was just released and contains the fix for this issue.
- locked and limited conversation to collaborators
on Dec 19, 2020
[REQUIRED] Please fill in the following fields:
[REQUIRED] Please describe the issue here:
Unity Editor becomes non responsive on play if a Firestore transaction was made in the previous session.
Steps to reproduce:
Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)?
Haven't tried yet.
What's the issue repro rate? (eg 100%, 1/5 etc)
100%
What happened? How can we make the problem occur?
Editor becomes non responsive.
Press play
Run code that makes a transaction
Press stop
Press play
Unity editor is now stuck
Relevant Code: