CTD from garbage collector trying to delete a null object

LoneGazebo · April 12, 2017, 4:07am

Hello everyone,

I’ve got a strange issue. Everything in my project is running fine, and has been for the past few days. Now, all of a sudden, I’m getting a CTD about 2-3 minutes into any session of the PIE running. The call stack is always the same:

UE4Editor-CoreUObject.dll!TFastReferenceCollector<FGCReferenceProcessor,FGCCollector,FGCArrayPool,0>::ProcessObjectArray(TArray<UObject *,FDefaultAllocator> & InObjectsToSerializeArray, TRefCountPtr<FGraphEvent> & MyCompletionGraphEvent) Line 293	C++
>	UE4Editor-CoreUObject.dll!TGraphTask<TFastReferenceCollector<FGCReferenceProcessor,FGCCollector,FGCArrayPool,0>::FCollectorTask>::ExecuteTask(TArray<FBaseGraphTask *,FDefaultAllocator> & NewTasks, ENamedThreads::Type CurrentThread) Line 883	C++
 	UE4Editor-Core.dll!FTaskThreadAnyThread::ProcessTasks() Line 1277	C++
 	UE4Editor-Core.dll!FTaskThreadAnyThread::ProcessTasksUntilQuit(int QueueIndex) Line 1171	C++
 	UE4Editor-Core.dll!FTaskThreadBase::Run() Line 643	C++
 	UE4Editor-Core.dll!FRunnableThreadWin::Run() Line 76	C++
 	UE4Editor-Core.dll!FRunnableThreadWin::GuardedRun() Line 25	C++
 	[External Code]

Looking at the Object being passed into the FGCReferenceProcessor, it is NULL, thus the garbage collector is trying to delete an object that isn’t there. The callstack above is relatively light on details as to connections to my project, thus I am curious if there are any steps I can take to figure out what object is being passed into the GC this way, and why.

Thanks!

anonymous_user_41845f4a · April 12, 2017, 5:00pm

Hello LoneGazebo,

Although you do say that this happened all of a sudden, usually issues like this are caused by changes made. Can you think of any changes that you may of made in the project the last time you were working on it?

I have a few questions to ask to gather information as well:

Is this a code project or a Blueprint only project?
Are you using a Binary editor (From the Epic Games Launcher) or a source built one?
Do you have any backups of your project or any source control in place that could allow you revert changes and possibly see what is causing this? If not, despite the issue, I would suggest getting something of the sort set up for cases like this.
Are you able to reproduce this in a fresh project?

LoneGazebo · April 12, 2017, 5:18pm

Hi Matthew,

It is a mix of C++ and blueprint (blueprints only used for UI, initialization of level, and camera work).
Launching via VS 2015 in Development Editor mode
Yeah, we’re using git for nightly builds - I reverted and the CTD is temporarily gone, though I’m curious as to why it would appear. We’re using the UPROPERTY method for all data elements in the DLL. The changes included in this nightly were related to a new material instance used for water (based on the UE example template for waves/ocean) and the generation of a collection of actors (one per tile on a hexagonal planet). These were all handled using GC-safe methods (or so I believe, using UPROPERTY). Furthermore, since the CTD is not occurring at runtime, but rather 3+ minutes afterwards, I’m doubly confused.
Reverting the nightly removed the CTD, so I don’t know that I need to attempt this.

I am curious, though, if the error lies in a custom third party library we are using. The library generates the parameters for our planetary mesh, which I import via the following method:

std::shared_ptr<IPlanet> planet((IPlanet*)malloc(sizeof(IPlanet)), free_delete());

free_delete is defined as such:

struct free_delete
{
	void operator()(void* x) { free(x); }
};

This method is present in the nightly and the previous version, and does not cause a 3+ minute CTD, so I think it is fine.

Thank you for your time, looking forward to hearing from you.

anonymous_user_41845f4a · April 12, 2017, 5:51pm

Thank you for the information. As for question 2, that’s not quite what I meant. I meant are you using the Binary editor (The one downloaded from Epic Games Launcher, which comes pre-built) or an editor built from the source code downloaded from Github.

As for the changes that you made that caused this crash to occur, the generation of a collection of actors seems like the most likely culprit. Have you tried running the project in Debug through Visual Studio? You could try using this and watching the values of these generated actors to see if they are being garbage collected for some reason.

Can you also please submit the crashes that you have been experiencing so that I can look these up in our database? This could help me link it to any other existing reports that may of had resolutions.

LoneGazebo · April 12, 2017, 6:24pm

Sorry, misunderstood #2. I’m using the launcher editor, not a source code built one.

I’ll try regenerating the actors. If I get a crash, I’ll submit the logs here.

Thanks!

LoneGazebo · April 13, 2017, 4:15am

Stepping back through the nightly build, the CTD stems from the assignment of a dynamic material - the material is called via ConstructorHelpers::FObjectFinder and then passed to a UPROPERTY pointer to a materialinstance in the class. The original call is not used again, so if it is passing out of scope it shouldn’t be a problem, correct? Or have I misunderstood FObjectFinder?

Thanks again for your help.

anonymous_user_41845f4a · April 13, 2017, 1:34pm

Could you please provide the code for the constructor itself? It’s hard to debug code without seeing the code. If any variables included are declared outside of the code shown, please define what type they are. You can either post the code here or use a site such as Pastebin.

LoneGazebo · April 13, 2017, 2:32pm

Here is the code:

FString WaterInstance = FString(TEXT("'/Game/Materials/M_Water_Master_Inst.M_Water_Master_Inst'"));
	ConstructorHelpers::FObjectFinder<UMaterialInstance>MaterialInstance(*WaterInstance);
	WaterMaterialInstance = MaterialInstance.Object;

And here is the uproperty element for that actor:

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "PlanetActor")
		UMaterialInstance* WaterMaterialInstance;

I intend to eventually replace these hard call with database lookups once we’re passed the debug phase.

Thanks again.

LoneGazebo · April 13, 2017, 3:01pm

I will try both of these steps and report back, thanks.

anonymous_user_41845f4a · April 13, 2017, 2:59pm

Thank you for the code. I’m curious however, is there a reason for dereferencing the FString you’re passing in for FObjectFinder? Usually I would see FObjectFinder used like so, usually forgoing the FString declaration as well since it isn’t reused:

ConstructorHelpers::FObjectFinder<UMaterialInstance>MaterialInstance(TEXT("'/Game/Materials/M_Water_Master_Inst.M_Water_Master_Inst'"));

If changing this doesn’t help, can you try commenting this part out and setting the material in the blueprint itself, assuming that you’re blueprinting this class since the UProperty is BlueprintReadWrite?

anonymous_user_41845f4a · April 21, 2017, 7:07pm

We haven’t heard from you in a while, LoneGazebo. Are you still experiencing this issue? If so, were you able to test what I had mentioned? What were the results? In the meantime, I’ll be marking this issue as resolved for tracking purposes.

LoneGazebo · April 22, 2017, 4:19am

Hi Matthew,
Sorry for the delay, I’ve been out of town on business. I’m still seeing the crash, however it is sporadic and (since I removed the offending code) doesn’t seem to be tied to the issue above. Sometimes it occurs, sometimes it doesn’t, and I fear that it is somehow related to the memory on my workstation.

I’m going back out of town this week, but can send in a copy of our project code if needed if/when I can find an easily-reproducible crash. For now, however, I think the original issue can be considered resolved (as the code is no longer used).

Thanks again for your help.