You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Features in External Dependency Manager in use: CommandLine
Plugins SDK in use: Firebase
Platform you are using the Unity editor on: Linux
[REQUIRED] Please describe the issue here:
While using Unity editor in batch mode on Linux we can meet the race condition inside CommanLine class, especially in AsyncStreamReader.
Steps to reproduce:
Make sure there are no Library and Temp folders. It's important to reimport the project from a clean state before every start otherwise Firebase's AssetPostprocessor won't work.
Launch Unity with such arguments: /Unity/Hub/Editor/2020.3.41f1/Editor/Unity -projectPath ./ -batchmode -quit -logFile /dev/stdout. Be careful: you must use batch mode, not GUI.
Please answer the following, if applicable:
What's the issue repro rate?
Pretty often (I would to say more than often), but not 100% - can't find a strict dependency. But I can say the following things:
removing Firebase.Editor.dll solves the problem. Repro: 0;
removing shaders from project solvers the problem too. Repro: 0;
using them together causes troubles.
What happened? How can we make the problem occur?
The problem appears when Unity executes Firebase's realization of AssetPostprocessor class. There is a sequental execution of Python scripts inside it. On the first step the script tries to determine installed version of Python via runing python --version by CommandLine: https://github.com/firebase/firebase-unity-sdk/blob/main/editor/app/src/PythonExecutor.cs#L129
You are lucky to find the issue at first try if you see these log entries:
If nothing happens after 10 seconds, connect a debugger and pause the program to see what's going on. I use Rider, so the screenshots will be from there. These are the points in different threads where resolver execution suspends:
CommandLine.AsyncStreamReaderMultiplexer waits for queued item to be ready to read:
CommanLine.AsyncStreamReader hasn't got a signal to free read event and thus hasn't fired DataReceived callback with completion argument:
Following the facts above we can't go on without complete event inside RunViaShell being set:
In all cases, where the problem appears, DataReceived callback in CommanLine.AsyncStreamReader would never be fired with complete == true.
It occurs immediately after the start of shader compilation, that's why I provide a bunch of the shaders along with project. Can't be sure either it's a race condition between different parts of engine or maybe a deadlock inside resolver.
The only one way to skip the waiting is to kill Unity process and run it again. But it's a completely not a solution for CI/CD environment. 😿
The text was updated successfully, but these errors were encountered:
Thanks for the detailed bug report. I'm really not sure what the root cause might be, I don't think we've seen anything like that, and we do regularly use the batch mode to test the Firebase SDKs, including on Linux. I can try to reproduce this with what you have provided.
I assume there shouldn't be a problem finding python, but if you do find out any more info please let us know.
CheeryLee
added a commit
to CheeryLee/unity-jar-resolver
that referenced
this issue
Mar 10, 2023
Well, while you are trying to investigate the problem, I've managed to make a dirty workaround. It stops AsyncStreamReader after 10 seconds of waiting for reading from any of pipes. I don't think that it looks like a full-fledged solution, but it's enough for our purposes.
I'm still staying tuned for any updates of this issue.
[REQUIRED] Please fill in the following fields:
[REQUIRED] Please describe the issue here:
While using Unity editor in batch mode on Linux we can meet the race condition inside CommanLine class, especially in AsyncStreamReader.
Steps to reproduce:
cd /path/to/unpacked/project
/Unity/Hub/Editor/2020.3.41f1/Editor/Unity -projectPath ./ -batchmode -quit -logFile /dev/stdout
. Be careful: you must use batch mode, not GUI.Please answer the following, if applicable:
What's the issue repro rate?
Pretty often (I would to say more than often), but not 100% - can't find a strict dependency. But I can say the following things:
What happened? How can we make the problem occur?
The problem appears when Unity executes Firebase's realization of AssetPostprocessor class. There is a sequental execution of Python scripts inside it. On the first step the script tries to determine installed version of Python via runing
python --version
byCommandLine
:https://github.com/firebase/firebase-unity-sdk/blob/main/editor/app/src/PythonExecutor.cs#L129
You are lucky to find the issue at first try if you see these log entries:
If nothing happens after 10 seconds, connect a debugger and pause the program to see what's going on. I use Rider, so the screenshots will be from there. These are the points in different threads where resolver execution suspends:
CommandLine.AsyncStreamReaderMultiplexer
waits for queued item to be ready to read:CommanLine.AsyncStreamReader
hasn't got a signal to free read event and thus hasn't firedDataReceived
callback with completion argument:complete
event insideRunViaShell
being set:In all cases, where the problem appears,
DataReceived
callback inCommanLine.AsyncStreamReader
would never be fired withcomplete == true
.It occurs immediately after the start of shader compilation, that's why I provide a bunch of the shaders along with project. Can't be sure either it's a race condition between different parts of engine or maybe a deadlock inside resolver.
The only one way to skip the waiting is to kill Unity process and run it again. But it's a completely not a solution for CI/CD environment. 😿
The text was updated successfully, but these errors were encountered: