Adding element to Array in base blueprint causes crash when It attempts to propagate changes to edited version in child blueprint

On my Actor blueprint I have an array of blueprint defined structs which contains an array of a c++ defined struct.
If we have a child which has an edited version of the array whenever I attempt to add elements It causes a crash.

I’ve reproduced the crash in a very simple project HERE.
Specific Repro steps are:

  1. Open the BaseActor blueprint.
  2. Add an entry to the ‘SoundArray’ variable in the object properties (Not the default value of the property)
  3. Attempt to add an element to the ‘CueData’ array

And the Editor should crash at this point. The cause being the change being propagated to the ‘ChildEditedActor’ Blueprint which has locally changed the ‘SoundArray’ variable. If the ‘ChildEditedActor’ is deleted the editor has no issues propagating the change to the ‘ChildActor’.

That should hopefully be all the information required. Let me know if you need further info.

Cheers.

Question on step 2: There is no instance of the blueprint in the level, so the only place I can add something to SoundArray is in the default values?

Hey FacePalm.exe,

I’m also curious regarding where to add the entry to SoundArray. Could you please clarify your second step?

There is 2 places in the blueprint editor you can change the value: clicking the created variable in the Variable list or by clicking the Actor Properties in the component view.

The latter is the correct one. I’m not sure if they follow different code paths or not, as I wrote this bug report after I did a temp fix locally.

So I’ve provided the one I am certain crashes.

Picture for further clarity:

Thanks for the clarification. I was thinking that’s what you meant but I didn’t experience the crash so figured I’d clarify.

So I’ve tested this now following your original repro steps and added an element to Sound Array, and then adding an element to Cue Data, but I’m not getting a crash. I’m running 4.15.1 built from source.

Are you also on 4.15.1?

We’re currently running just 4.15 Source, after grabbing the 4.15.1 build and giving it a go it does not crash as you say.

I did some debugging on 4.15 and the issue was the code wasn’t catching a NULL ptr correctly.
I did a quick diff of the two codebases around the same area, and the code hasn’t changed.

I’m assuming code has changed elsewhere to stop that specific case from happening, however there may possibly be other cases which could crash.

The specific issue is that UArrayProperty::ExportTextItem() doesn’t properly handle the case of ‘PropertyValue’ being NULL

So further up the chain in FPropertyNode::PropagateContainerPropertyChange() the following code will crash if Addr is ever NULL for an array property:

......
		if (ActualObjToChange != ModifiedObject)
		{
			uint8* Addr = NULL;

			if (ChangeType == EPropertyArrayChangeType::Add || ChangeType == EPropertyArrayChangeType::Clear)
			{
				Addr = GetValueBaseAddress((uint8*)ActualObjToChange);
			}
			else
			{
				Addr = ParentPropertyNode->GetValueBaseAddress((uint8*)ActualObjToChange);
			}

			FString OriginalContent;

			// This call causes the crash as 'Addr' could be NULL when the property is an array
			ConvertedProperty->ExportText_Direct(OriginalContent, Addr, Addr, NULL, PPF_Localized);

			bool bIsDefaultContainerContent = OriginalContent == OriginalContainerContent;

			// The rest of the function correctly checks if 'Addr' is NULL
			if (Addr != NULL && ArrayProperty)
			{
.....

So with the original bug ‘Addr’ was NULL and it wasn’t handling it correctly.

This should probably be fixed to stop similar cases in the future.

I’m glad to hear that your issue was resolved in 4.15.1. As far as the issue you reported with ExportTextItem() and PropogateContainerPropertyChange(), you are more than welcome to go ahead and put in a pull request for this if you have a fix in mind.

Otherwise, if you have a functional example of where this code could cause a crash, feel free to provide that as well and we can investigate and get a ticket in. Without a functional example, it’s tough to get a ticket in due to the process that we follow for entering bug reports, which require a set of steps to reproduce or a project that showcases the issue.

Have a great day