If two C++ UClasses exist with the same name then the unreal header tool crashes with a “CrashOrAssert”, coming from an assert in file HeaderParser.cpp, in void FHeaderParser::CompileClassDeclaration(FClasses& AllClasses):
…
// Verify class variables haven’t been filled in
check(Class->Children == NULL);
…
Now obviously having two classes with the same name is surely something you should not do. However it can happen accidently:
you want to move a file but you copy it by accident, or you forget to delete the source file
you do some Code Versioning Commands with unwanted side effects
This leaves the developer with no clue as to why UHT is failing. A simple “UCLASS with same name ‘XXXX’ already exists” can really save some time here.
Steps to reproduce:
Create Unreal C++ Project
Add A UCLASS Definiton UMyClassExistsTwice
Add A another UCLASS Definiton UMyClassExistsTwice in a different physical place
compile project
Actual Result (Visual Studio Output):
...
1> C:/work/doi/Source/doi/Common/DoiObjectSocket/DoiObjectSocket_Dto.h(15) : LogWindows:Error: Windows GetLastError: The operation completed successfully. (0)
1> C:/work/doi/Source/doi/Common/DoiObjectSocket/DoiObjectSocket_Dto.h(15) : LogWindows:Error: === Critical error: ===
1> Assertion failed: Class->Children == NULL [File:C:\work\UnrealEngine-4.10.4-release\Engine\Source\Programs\UnrealHeaderTool\Private\HeaderParser.cpp] [Line: 4605]
1>Error : Failed to generate code for doiEditor - error code: CrashOrAssert (3)
1> UnrealHeaderTool failed for target 'doiEditor' (platform: Win64, module info: C:\work\doi\Intermediate\Build\Win64\doiEditor\Development\UnrealHeaderTool.manifest).
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.MakeFile.Targets(38,5): error MSB3073: Der Befehl "C:\work\UnrealEngine-4.10.4-release\Engine\Build\BatchFiles\Build.bat doiEditor Win64 Development "C:\work\doi\doi.uproject" -waitmutex" wurde mit dem Code -1 beendet.
Attempting to add multiple classes through the editor gives an error when naming the second class before being able to actually create it. I received a similar error when attempting to create two classes through Visual Studios.
To create two classes with the same name I had to copy the class from the file explorer. If I did this with a blank class created from inside Visual Studio, the game code could still compile successfully. If I created the class via the editor and then copied it, I received the following compile errors in VS. In neither case did UHT crash.
Please explain how you’re creating the classes and what code is in the classes. Please also let me know exactly when the crash occurs and what you were doing when it occurred as well as provide the callstack and log file from the crash.
Ok, I see. I guess there is also some race condition. I also noticed that I “lived” with the double uclass for a longer time, around 6 months I think, so I had plenty of full rebuilds without any error.
That makes it even much harder to find the cause for the UHT error - if the file action was recent you could maybe guess it is a problem on file level, but if it appears 6 month later…
I guess you would need a copy of my project folder (and maybe my cpu) to reproduce the problem in a stable manner. With my actual configuration I can however reproduce it in a very stable way.
Another thing: What happens when you have two definitions for the same class? Isn’t that very bad? Which one actually becomes valid? Or do they get “joined” somehow? As far as I know UE does not support “partial classes” as in certain programming languages, so the header tool should throw an error if it encounters the same UClass definition twice - or am I wrong?
What if people try to edit the “first” definition but unreal takes the “second” one? I guess it can really cause weird behaviour…
Can you provide an example of the code you’re using where a class is being defined twice? Additionally, can you explain the steps for how you’re creating both classes? Are you doing so through the editor or through VS or something else?
We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will follow up.
