Unusual Access Violation upon setting a Member of a C++ Class

An access violation during the initialisation of the main character is causing the editor to crash whenever it starts up; access violations are typically causes by logical errors, such as de-referencing a pointer that points to null, however, this issue is beyond any logical explaination which leads me to believe that there at the very least there is a leak in the documentation of Unreal Engine or, at worst, a bug.

Despite the fact that logs were available, they offered absolutely void assistance to pinpointing the cause of the access violation. After several hours of analysis, I have been able to locate the error. Let me show you a simplified version of the code, before I elaborate:

UCLASS()
class BLAKEARROW_API ULivingInventory : public UObject
{
	GENERATED_BODY()
protected:
	/** The item in the primary hand, commonly a weapon - shall never be null */
	UPROPERTY(EditDefaultsOnly, Category = Equipment)
	UItem* PrimaryHand;
public:
	/** Sets the primary item in hand */
	UFUNCTION()
	void setPrimaryItem(UItem* newPrimaryWeapon)
    {
        if (newPrimaryWeapon)
	    {
             PrimaryHand = newPrimaryWeapon; // exactly this line causes the access violation
	    }
    }
};

I am omitting the actual class that ULivingInventory inherits from because it makes no difference; what is important is that is ultimately inherits from UObject and as such is managed by the garbage collector. Despite the fact that the error log does not represent this error message I am certain that this line causes the error; I have tried omitting it and then everything runs just fine.

This code is executed in context of the main character’s post–construction constructor(the one accepting FObjectInitializer). Let me show the relevant snippet of code in the constructor:

// a class member of the character in .h file is:

    /** The living entity meta data */
    UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = Meta)
    ULivingEntity* EntityMetaData;

// in .cpp file:

AExampleCharacter::AExampleCharacter(const FObjectInitializer& ObjectInitializer)
	:
	Super(ObjectInitializer)
{
	// ... unrelated attributes beforehand: collision component, camera,  mesh, and input

	EntityMetaData = NewObject<ULivingEntity>();
	UInventory* inv = EntityMetaData->getInventory();
    ULivingInventory* invent = (ULivingInventory*)inv;
    UProjectileLauncher* launcher = NewObject<UProjectileLauncher>();
    invent->setPrimaryItem(launcher); // uncommenting this line, again, prevents the access violation
   // invent is not null, however
}

The exact defintion of the ULivingEntity does not matter except matter except that the method getInventory returns a ULivingEntity that has been constructed using NewObject. UProjectileLauncher inherits from UItem, UItem inherits from UObject, more details should not be required, but I shall provide them upon request.

I have never received an access violation when setting fields variable before unless the object I was setting it in itself was null, which cannot be the case, obviously, because the method is successfully called; in other words, the local variable “invent” is not null (tested as well). Also, I encourage you to take a look at the logs which I have uploaded. It pinpoints to an access violation is the class TSet, which makes void sense because nowhere in my code I use TSet, as such, it is some hidden operations under the hood causing this error.

My conclusion is that the runtime provided by Unreal Engine is messing things up as I am not calling any code directly which is indicated in the logs.

Upon request, I shall also attach the source of all other classes.

I have also uploaded the logs: link text

Hello Univise,

Thank you for the information you provided. Unfortunately I’m not having any luck reproducing the issue itself which is the first part of our bug reporting process. Would it be possible to get a copy of your project, or even a sample project where the crash occurs? If you wish for the project itself to remain private you can send a private message to me on our [forums][1],

Hi Univise,

We haven’t heard from you in a while. Are you still experiencing this issue? If so, please leave a comment to let me know. In the meantime, I’ll be marking this as resolved for tracking purposes.