[C++] Crash on calling a function on self or assigning a specific variable

In one of my source files, a UComponent subclass, strange crashes occur that really remind me of memory corruption. These bugs occur only after I enter a level multiple times, serializing and deserializing the actors containing the component that causes problem.

All crashes report the Access violation - code c0000005 (first/second chance not available) error

These are the bugs I found so far :

void UEmoteComponent::SetEmote(EEmote emote) {

	switch (emote) {
	case EEmote::NONE:
		SetSkeletalMesh(nullptr);
		break;
	case EEmote::SALE:
		FindAndSetMeshSale();
		break;
	case EEmote::ANGRY:
		FindAndSetMeshAngry();
		break;
	case EEmote::HAPPY:
		FindAndSetMeshHappy();
		break;
	case EEmote::GOOD:
		FindAndSetMeshGood();
		break;
	}
        Emote = emote; //The crash happens here
} 

Here is the variable as declared in the .h :

UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Game|NPCs|Emotes")
	EEmote Emote;

Whenever this variable is assigned, the game crashes.

If I try to set the variable in the switch block instead, the error is reported elsewhere :

void UEmoteComponent::SetEmote(EEmote emote) {

	switch (emote) {
	case EEmote::NONE:
		SetSkeletalMesh(nullptr);
		Emote = emote;
		break;
	case EEmote::SALE:
		FindAndSetMeshSale();
		Emote = emote;
		break;
	case EEmote::ANGRY:
		FindAndSetMeshAngry();
		Emote = emote;
		break;
	case EEmote::HAPPY:
		FindAndSetMeshHappy();
		Emote = emote;
		break;
	case EEmote::GOOD:
		FindAndSetMeshGood(); // The crash happens here
		Emote = emote;
		break;
	}
	//Emote = emote;
}

This is weird as this function call works fine unless the assignment of “Emote” is there.

  1. If I remove all instances of Emote = emote from SetEmote, the game crashes in another function :

    void UEmoteComponent::ScheduleEmoteReset(float time) {

    AActor* owner = GetOwner(); //The crash happens here
    if (owner) {
    	UWorld* world = owner->GetWorld();
    	if (world) {
    		FTimerHandle resetHandle;
    		world->GetTimerManager().SetTimer(resetHandle, this, &UEmoteComponent::ResetEmote, time, false);
    	}
    }
    

    }
    If I comment out this code too the game works normally. What is strange is that the crash happens when simply calling GetOwner() or GetWorld() (even if the entire line of code is GetOwner();).

Normally, even if GetOwner() returned a nullptr, assigning it to a variable wouldn’t cause problem. I also check if the pointer is valid before using it.

Another strange thing about these crashes is that the stacktrace end there. For example, when calling GetOwner(), the crash reporter shows that it doesn’t enter GetOwner, it crashes on the call.

These errors look like null pointer exceptions, however the pointer in question is “this”.

The only two things I can think of right now are either 1) memory corruption or 2) the crash reporter doesn’t show me the right error / right line where the error occurs.

Thank you for your time

Hey-

Can you provide the full callstack and log files from the crash for additional information? Also, if you’re able to reproduce this crash in a new project, can you provide the setup steps or sample project itself to help us reproduce/test the crash locally?

Hey

Since I posted my question, I made some changes to my game and the crash doesn’t occur anymore.

Strangely, putting the this->Emote = emote; at the start of the function seemed to fix it.

The crash seemed to occur on actors that I had serialized and then deserialized (I do this when I change levels), because the component in question wasn’t valid. However, it only happened on blueprint actors whose class were referenced by some class, anywhere. For example, after removing all references to the class, the crash stopped. After adding a new variable in my level blueprint (that I didn’t use anywhere), and setting the default to this class, the crash occurred.

I haven’t found a way to reproduce the crash, as it seems very specific, and it doesn’t affect me anymore, so I am going to mark the thread as resolved. If I run into this bug again, I’ll try and look into it more in depth.