I’m trying to compile our project after converting it from 4.8.2 binary to a source build from the github master branch (labelled 4.10 as of now).
UE4 compiles just fine, but when compiling the project I get this error: UnrealBuildTool Exception : error : Mutex Global/UnrealBuildTool_Mutex_1963014909 already set, indicating that a conflicting instance of E:\ue4\Engine\Binaries\DotNET\UnrealBuildTool.exe is already running.
There isn’t any other instance of UBT as far as I can tell, having restarted multiple times. Is there something I can do to clear up the mutex error?
We generally don’t encourage development on the github master branch since it has not had any stability testing. If you are wanting to switch from binary to source code then it would be best to work off of the Release branch since this is the most likely to work reliably. Let me know if you are still getting errors when opening the project from a Release branch version of the engine.
I fixed it on my side by disabling the UE4 build target from my project’s “Development Editor” dependencies. I always do the engine build separately anyways so there is no need to rebuild it as part of my module/project.
Changed “Maximum number of parallel project builds” to 1. This fixed it for us, albeit a very strange bug to begin with. Can someone from Epic shed some light on this?
Was the VS solution open when you converted the project? After converting the project did you receive the error every time you attempted to compile?
I created a project in 4.8.3 binary and converted it to the master branch from GitHub. With the solution open during the conversion I received the same message described in the original post. However closing/reopening the .sln file allowed me to successfully build the project. It appears that with the solution open it was reading UBT as running from the actual conversion process as well as the build attempt.
Negative, I also did a reboot. Still have the same issue today (Whether I build from Frontend or VS2013 doesn’t matter). Worth noting; I pulled the 4.9 branch (not the master branch)
I downloaded the 4.9 branch this morning and converted a 4.8.3 binary project to 4.9 source. Doing so I had the same result of receiving the error but having it go away after closing the VS solution and reopening it. Based on the answer you posted it sounds as though you’ve found a solution for your project. If you encounter this again in the future let us know and will investigate further.
I’m having the same issue every now and then on the 4.9 branch. For now I fixed it by reverting the changes done in CL 2597203. Here is the error I get:
21>UnrealBuildTool Exception : error : Mutex Global/UnrealBuildTool_Mutex_-1973218247 already set, indicating that a conflicting instance of H:\dev\UnrealEngine\PZ4.8\Engine\Binaries\DotNET\DotNETUtilities.DLL is already running.
From what I’ve found this is caused when trying to build after converting a project version in place. In the cases that I’ve seen this message the project built successfully (and performed the hot reload). If you are receiving this error after switching engine versions for a project, you should be able to right click the project name in VS and Build only the project which should prevent the error from occurring. Alternatively, creating a copy when converting the project rather than converting in place should help avoid this message as well.
That’s a good workaround. As I explained in the Github comments on the commit:
This was done to be more like a normal tool that would fail immediately if their preconditions are not met. Letting UAT/UBT wait on the mutex would hide unknown serializations of UBT executions that looked like they were being run in parallel, extending build times and causing unexpected hangs as UBT processes would instead be stuck waiting for another process without any feedback to the user.
A common cause of this is using the Visual Studio “Build Solution” option to build your solution, which will try to kick off non-dependent projects in parallel, which UBT will then silently serialize. Silent serialization like this was not considered a desirable workflow, but does render the “Build Solution” option pretty much useless now, though your workaround will probably help. But in reality you rarely need this option. Many/most of the projects in the solution are unrelated to building your game or editor. If you use the UnrealVS plugin (which we provide) you can leverage the “Batch Build” dialog to schedule groups of builds that are custom-tailored to your needs, and save off combinations that you commonly use.
The mutex is essentially per-branch because the mutex hash is based on the full path to the UBT executable, and in situations where you know it is safe, you can add -NoMutex to your invocation of UBT.
When is it safe to use -NoMutex? Well, that’s thornier, thus why we don’t have documented guidelines. If you are using XGE, it’s never safe. You also can’t, say, build two editors for two different projects in the same branch at the same time. Finally, we have a global include dependency cache that is shared between all targets, rendering parallel runs of UBT that could possibly need to update the dependency cache very unsafe. there may be more reasons, but that’s probably enough right there.
Nice summary, thanks for taking your time and writing it out. I really appreciate it. Do you know of any “best practice” guides when it comes to using VS with Unreal? Right now all we’ve been doing is F5’ing the whole solution and debugging it from there.
Beyond the published Visual Studio Setup docs, I don’t know that there are any published docs relating to deeper programmer efficiency subjects like this, since workflows can be so different and varied, and various common third party plugins can change the most effective workflow strategies.
From a “trimming what you build before you run” scenario, I will say that I, as an engine programmer, usually just build my one active game/editor target when iteratively developing (I use UnrealVS’s Build Startup Project Hotkey for this), and UnrealVS batch JobSets that select more games and platforms when I am ready for “wider compile testing”. However, gameplay folks would probably prefer hot-reloading modules and iterating in Blueprints/content first. Platform folks might need to set up Cook-on-the-Fly and things like that to get changes to their platform as quickly as possible. It all depends on what is the gating factor for your efficiency. Scenarios where you can avoid shutting down the editor or reloading your scene is the holy grail of iteration, and we try to enable as many of those scenarios as we can for gameplay situations. Engine folk don’t tend to have as many options there.
After further internal discussion and investigation of some alternatives to serialize UBT executions from Visual Studio builds, we have restored the old functionality though a -WaitMutex parameter that will be automatically added to the build step of each project when you run GenerateProjectFiles. This was submitted in CL#2678456 (visible on Github here).
We apologize for the inconvenience, and will try to keep “Build Solution” workflows in place going forward, and have added this to our QA testing process. Please continue to bring anything that slips through the cracks to our attention, as only few people internally use this workflow.
