4.18 Preview 4; No issue in 4.18 Preview 1 and possibly Preview 2
Reproducible from specific project but not from empty project.
I have a few blueprints in my project that immediately crash the editor upon loading in any way, be that while loading a level that has them, opening the blueprint itself, or even in a clean blueprint when selecting the problem blueprint as a variable type. I also cannot right-click the blueprint’s thumbnail in the content browser without it also triggering the same crash. The same thing happens to their child blueprints.
I don’t know what it is about these blueprints that makes them behave like this. I would be happy to test out things and provide more specific detail, I just don’t know where to begin on something like this.
One thing I’m getting in the crash reporter summary is a “Stack overflow - code c00000fd (first/second chance not available)”
If you would like to provide your project, you can do so by zipping it down and providing it via a dropbox or google drive link. As for the crash report, you should be seeing a window pop up with the project crashes (see example below). I will need you to provide all of the information in that window.
Quick suggestion:
If you copy the files through windows explorer to another project (one corrupt blueprint at a time) are you able to open them (note: this will likely break all the references in the blueprint(that is expected))?
Crash reporter window:
I will look like this except there will be a callstack in the blank area. Please provide all of the information in the callstack (including machine ID)
It works until I copy over a specific blueprint, which I may be able to rewrite if I have to, but would be nice to see how complex it is in case I’m underestimating how much it does.link text
In the past, I had this problem quite frequently with circular dependencies in blueprints. I know UE4 handles them a bit better now, but I assume a complex blueprint with a lot of references could still have the same problem. This occurs when you are dynamic casting to other blueprints:
Blueprint A dynamic casts to Blueprint B to access a variable in blueprint B
Blueprint B casts to Blueprint A to access a variable in blueprint A
When you begin to load Blueprint A, it tries to load Blueprint B, which Blueprint A depends on
Blueprint B depends on A, and it tries to load Blueprint A
The biggest solution to this is using blueprint interfaces or casting to a C++ parent class.
As I stated previously, Epic has done a lot of work to fix circular dependency problems, but I assume they would still occur with a lot of dependencies. If you haven’t been using interfaces, I would assume that would most likely be the reason for crashing. The reason it would work in another editor is because the blueprint (most likely) would throw an error when it can’t load certain dependencies.
Interesting. Yeah I just opened a clean project with only that problem bp in there and it does open. It’s possible I was editing it and accidentally did something circular like that. For some reason I remember everything being fine until I updated to the next preview version, which then cause it to crash on load. Regardless, it’s probably a chunk of code that needs a major overhaul anyway. Thanks.
Yea I’m sorry my answer isn’t really a ‘fix.’ For blueprints, make it a habit to never cast to another blueprint. Use an interface or cast to a C++ class. This way you never need to worry about circular dependencies.
I have run a few tests and I am unable to reproduce this issue on our end. Are you still experiencing this issue? If so, could you provide the complete callstack including machine ID? Please keep in mind that you may need to install you debugging symbols. This can be done in the launcher under options.
I’ve since deleted the problematic blueprint from my project and decided to rebuild it. However I had the project in its non-functional state in git history so I revived it momentarily to produce the error logs. Thank you for your dedication to my issue.
I am happy to hear that you a were able to to find a solution/workaround to the issue that you were having. Thank you for the information provided. However, this does not contain the callstack. As mentioned by walk12288, the issue may have been caused by a circular reference. Were you able to confirm this?
We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will follow up.
