Text.TextData.Object was nullptr - crash

I’m pretty sure this might be project related, most likely my character blueprint.
But something changed in the 4.11 branch of the engine about 3 weeks that is causing a crash.

My c++ project works in 4.10.4 & Release4.11.p5 Branches with no errors.

In 4.11 Branch when I try to open a blueprint that references my character.


text.cpp line 66


Exception thrown: read access violation.

Text.TextData.Object was nullptr.


I am running 3 versions of the editor. All from Github source pulled via Visual Studio 2015 Team Explorer.

Branch 4.10 82c6eea5 2/19/2016 - All works as expected, no errors.

Branch Release fc6dc035 2/9/2016 - All works as expected, no errors.

Branch 4.11 4b4fcf7a 2/19/2016 - Crash (was working 3 weeks ago on this branch)


I use Perforce as source control, I have a depot and workspace for each version of my project. When I change a file in 4.10 and submit it to the depot, then I will merge/integrate/resolve it to the 4.11 project workspace to update the file there. This has worked since 4.11 preview 1 came out.

Could I get the full callstack? TextData is a shared-ref, so should never be null unless the FText instance has been zeroed in memory (we used to have some places that did that, but they should have all been fixed by now).

Hi Jamie,
Here is a txt of entire log.
link text
Jamie (same name) :slight_smile:


Would it also be possible for you to run the editor from Visual Studio (with the debugger attached) and paste me the callstack when the crash happens (or I can try and find the crash on our servers if you’ve submitted a crash report)?

I’ve been unable to send a crash reports. I built the CrashReportClient listed in Programs in the solution explorer but didn’t seem to work. If I run the editor with or without VS no crash report window appears.

I copied the text in the callstack tab in VS after it breaks
link text

Great, thanks :slight_smile:

I passed this on to the Blueprints team, and they suspect it may be a cycle on load, potentially caused by some recent changes to verifying package loading (more specifically, it may be this change).

Are you able to copy the BP with the issue into a new project and still have the crash happen? I realise it may be dependent on your other assets or source code, but we’d be really interested in getting our hands on something that can repro this crash so we can try find the offending change. You can email anything to us that you don’t want to share publicly.

Alternatively, if you wanted to regress this yourself since you’re building from source then that would be excellent. If you did this, the first port of call would be to try undoing the change I linked to above to see if that resolved the issue.

I am not sure if I was able to just uncommit 0b74af71 and keep all the commits after it.

So I made two local branches in Visual Studio, the image shows the results. It looks like 0b74af71 is where the break starts.

I created a new project and migrated my character into it, but it brought most of the other assets with it. The error is occurring in this project on branch 0b74af71 and works on 144cee1a.

What email should I use to send a download link to, it is 1.18gb?

You can email it to First.Last@epicgames.com, replacing First and Last with my actual name :slight_smile:

Once you do that I’ll raise a bug and pass it over to the BP team to investigate.

I got your email, but we’ve been having some issues trying to download the file (it always stops at ~300MB).

It’s worth noting that to minimise the download size, you only need to include the following data:

  • Config
  • Content
  • Source
  • YourGame.uproject

This may make the file small enough to download successfully from your current host, but failing that, is there any other way you can host this file?

Sorry, I’m uploading to a different host. I should have a link in about a half hour. I only included the above folders in the first link, the content folder is what has the large amount of data. :frowning:

Hi Sarlak,

Thanks for the project, it will help us figure out what is going wrong here. In the meantime, while we digest what is going wrong here, I’ve back out the original change that caused this. You can find that in 3ab9ef6.

Thank you so much for bringing this to our attention, as we were able to catch this before it went out in the final release.