[Bug] Possible race condition while using CommandLine

[CheeryLee]

[REQUIRED] Please fill in the following fields:

• Unity editor version: 2020.3.41f1
• External Dependency Manager version: 1.2.175
• Source you installed EDM4U: .unitypackage
• 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:

• Install python3 to your OS
• Clone a repo with a minimal reproducable Unity project: https://github.com/CheeryLee/EDM4U_TestLinuxFirebase
• Run cd /path/to/unpacked/project
• 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:

1. removing Firebase.Editor.dll solves the problem. Repro: 0;
2. removing shaders from project solvers the problem too. Repro: 0;
3. 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:

1. CommandLine.AsyncStreamReaderMultiplexer waits for queued item to be ready to read:

2. CommanLine.AsyncStreamReader hasn't got a signal to free read event and thus hasn't fired DataReceived callback with completion argument:

3. 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. 😿

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[a-maurice]

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]

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.