Breakpoint activated in GarbageCollection.cpp: Access violation - code c0000005 (first/second chance not available)

Development Programming & Scripting C++
, , , , , ,
1

I have added a new class to my project (this is a sub-class of another class, I can edit this post to include the class hierarchy if requested), implemented that class as desired and then, compiled the project successfully in Visual Studio 2013 and launched the editor via ‘DebugGame’, this was yesterday.

I intended to go back today to add in some new features, so I load up the project in Visual Studio 2013, changing several names of variables (all of them are of type Bool), attempt to get into the editor with the ‘DebugGame’ Solution Configuration, the project once again compiles successfully, but after loading all the required symbols, upon trying to load into the editor, at 91% progress, a break point is thrown by UE4 at this line within GarbageCollection.cpp:

// We can't collect garbage during an async load operation and by now all unreachable objects should've been purged.
		checkf( !Object->HasAnyFlags(RF_Unreachable), TEXT("%s"), *Object->GetFullName() );

Pressing continue, causes a message box with this message to be displayed:

Unhandled exception at 0x000007FEE9A40576 (UE4Editor-CoreUObject.dll) in UE4Editor.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

As well as activating another break point, at the line GetClass()->AppendName(Result); in UObjectBaseUtility.cpp:

/**
 * Returns the fully qualified pathname for this object as well as the name of the class, in the format:
 * 'ClassName Outermost.[Outer:]Name'.
 *
 * @param	StopOuter	if specified, indicates that the output string should be relative to this object.  if StopOuter
 *						does not exist in this object's Outer chain, the result would be the same as passing NULL.
 *
 * @note	safe to call on NULL object pointers!
 */
FString UObjectBaseUtility::GetFullName( const UObject* StopOuter/*=NULL*/ ) const
{
	FString Result;  
	if( this != nullptr )
	{
		Result.Empty(128);
		GetClass()->AppendName(Result);
		Result += TEXT(" ");
		GetPathName( StopOuter, Result );
		// could possibly put a Result.Shrink() here, but this isn't used much in a shipping game
	}
	else
	{
		Result += TEXT("None");
	}
	return Result;  
}

When trying to launch my project though the Unreal Launcher, the crash reporter for UE4 is shown instead, with these details of the issue:

MachineId: Edited out.
EpicAccountId: Edited out.
Access violation - code c0000005 (first/second chance not available)
UE4Editor_CoreUObject!UObjectBaseUtility::GetFullName() + 86 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\runtime\coreuobject\private\uobject\uobjectbaseutility.cpp:76]
UE4Editor_CoreUObject!FArchiveRealtimeGC::PerformReachabilityAnalysis() + 354 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\runtime\coreuobject\private\uobject\garbagecollection.cpp:448]
UE4Editor_CoreUObject!CollectGarbage() + 1514 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\runtime\coreuobject\private\uobject\garbagecollection.cpp:1132]
UE4Editor_UnrealEd!UEditorEngine::Cleanse() + 458 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\editor.cpp:1877]
UE4Editor_UnrealEd!UEditorEngine::EditorDestroyWorld() + 491 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\editorserver.cpp:1823]
UE4Editor_UnrealEd!UEditorEngine::Map_Load() + 3180 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\editorserver.cpp:2179]
UE4Editor_UnrealEd!UEditorEngine::HandleMapCommand() + 349 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\editorserver.cpp:5680]
UE4Editor_UnrealEd!UEditorEngine::Exec() + 797 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\editorserver.cpp:5180]
UE4Editor_UnrealEd!UUnrealEdEngine::Exec() + 273 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\unrealedsrv.cpp:742]
UE4Editor_UnrealEd!FEditorFileUtils::LoadMap() + 789 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\filehelpers.cpp:1910]
UE4Editor_UnrealEd!FEditorFileUtils::LoadDefaultMapAtStartup() + 216 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\filehelpers.cpp:3070]
UE4Editor_UnrealEd!FUnrealEdMisc::OnInit() + 2263 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\unrealedmisc.cpp:299]
UE4Editor_UnrealEd!EditorInit() + 3254 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\editor\unrealed\private\unrealed.cpp:86]
UE4Editor!GuardedMain() + 926 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\runtime\launch\private\launch.cpp:133]
UE4Editor!GuardedMainWrapper() + 26 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\runtime\launch\private\windows\launchwindows.cpp:126]
UE4Editor!WinMain() + 249 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.7\engine\source\runtime\launch\private\windows\launchwindows.cpp:202]
UE4Editor!__tmainCRTStartup() + 329 bytes [f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c:618]

This happened one time in the past, due to trying to cast the player’s pawn to a project’s GameMode, in an effort to get the GameMode, but I am not quite sure why this is occurring now, there are no invalid casts from what I can see, but I do believe there would seem to be an issue with a call to UObjectBaseUtility::GetFullName(), as well as how my project is handled by the Garbage Collector.

I am using engine version 4.7.6 and I used the binary version of the engine, as installed by the launcher, I would most wholeheartedly appreciate any assistance I can get in resolving this matter.

Edit 1 - 16/08/2015: I have attempted to modify the constructors of all my classes, but some of them require what I was trying to remove to test if the constructors could manage without it (but they cannot, certain classes of mine that inherit from engine classes that require an FObjectInitializer function parameter, to be passed via Super to the super class’s constructor), that was my attempt at modifying the constructors of my custom classes, please tell me if I should attempt another change to these constructors, this would be greatly appreciated.

2

First of all, “break point” means crash, VS automatically breaks the code for you to analize what happened. Also loading symbols has nothing to do with this crash, debugger loads symbols along side of running aplication, so your crash simply happens before all symbols are loaded, “symbols” are address mappings mapping your code file on machine code so debugger knows what specific line in machine code is line in source code.

the 2nd crash is not importent as normally application would stop on first one. The first one is caused in controllable way using check function. Check function s are functions that check conditions for proper code operation, if condition is not meet (in this case !Object->HasAnyFlags(RF_Unreachable), which means Object should not not have unreachable flag on) function print error log and crash the application. The comment describes why it is crashing:

“We can’t collect garbage during an async load operation and by now all unreachable objects should’ve been purged”

There “unreachable” object on load… what that means i don’t know :stuck_out_tongue: Usally crashes on engine load are caused by something constructor or general class configuration.

3

Thank you for the reply , ‘break point’ does not always mean crash, I am guessing that you are referring to the context of the engine though, in that ‘UE4 has triggered a breakpoint’, this would make sense, thanks for the snippet about symbols too, for reference, I also analysed the line of code mentioned in your comment’s second paragraph, in a similar manor before hand; !Object->HasAnyFlags(RF_Unreachable) indeed, this could be described as “Does this object not have any flags of ‘RF_Unreachable’”.

On to the comment where a breakpoint occurred in GarbageCollection.cpp, that would indicate that purging of ‘unreachable’ objects should have already occurred, either by other classes (or the same class, but another function etc.), or this purging is something I should have implemented, I am not quite sure of which of the two this is referring too, I presume the first case of already implemented purging that should have been done, is the case, but I ask you, could you tell me which of the two is what this comment is trying to indicate to whomever is reading it?

In addition in the final paragraph of your comment, you mention constructors, I will look over the ones in my project, checking them over to make sure there are no casts that would be impossible for example, general class configuration though, I honestly would not know how to modify that within Visual Studio, could you please tell me how this can be done on my end? If possible of course.

4

I am sorry for paragraphs of many words, to the point:

  • Should the comment in the first code snippet, that is from GarbageCollection.cpp indicate that purging should have already been handled by other classes/functions in the engine code, or by myself?
  • I will look over my class constructors, but is it possible to manage ones class configuration in VS2013 and if so, how?

This may help you save time, instead of reading my paragraphs of many words, which could make my points unnecessarily convoluted, I also did not mean any offense, in regards to the first line or so of my comment, indeed, appreciate your assistance most greatly, as I have received no feedback in my two other most recent questions on AnswerHub, my many thanks to you . :slight_smile:

5

To me it looks like internal engine problem, or else you really played with purging of objects but it seems thats not the case. Possibly your variable change mess up something in binaries, i don’t know. Maybe first try to compile empty UE4 code to see if it’s your code or UE4 code then try copying your code to other project.

6

Thanks , I created a first person shooter template project with 4.7.6, when I attempted to compile the code (with the same solution configuration), the project loaded up without a crash into the editor and I was able to play test the project, everything seemed to be working, so it would not seem to be the engine code.

Next, I tried creating a copy of my project, to open with 4.8.3, after copying my project, compiling the code for it, as well as letting the editor set itself up (compiling shaders and what not), this new version of the project opened in editor, there are issues with most of the blueprints, but at least it does not crash, thanks once again, for guiding me in the correct direction.

7

I have also compiled the project from code (with the same solution configuration as before), the code for the project compiles, loads symbols and then, launches into the editor.

So I believe that now, with your assistance, the problem has been solved, I will now have to modify most of the blueprints, to remove compilation errors from them though, but the issue I was having is non-existent, such a simple and straightforward solution, thanks for helping me see the wood through the trees , so to speak that is.

8

See the comments for how helped me find a solution, in a nutshell though:

  • I tried modifing my constructors, this had no effect
  • I tried to see if a new coded project template in 4.7.6 would load into the editor without crashing, this new project did
  • I opened a copy of my project in version 4.8.3 of the engine, to convert it to use that version, this opened with the epic games launcher, I then opened up the code solution in Visual Studio 2013 and attempted to debug from there, after compiling the project, the solution configuration I used loaded into the editor, without crashing, so I am now able to look at the Blueprints of my project, other assets too etc.

My greatest thanks then, are due to , my many gracious thanks once again for the assistance.