Hello there,
i’m facing the following problem:
My packaged game often crashes when opening playable levels.
I opened one in the editor and removed stuff until it succeeded loading 100% of the time.
It seems as if exceeding a number of certain bp_actors brings the chance of a crash on loading.
No idea why, though. The actors don’t cause errors in the editor or output log when packaging.
They consist of flipbooks, collision detection, interfaces and some scripts, which are not fancy either.
The crash log roughly looks like this (EXEPTION-ACCESS-VIOLATION happens every time.)
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffff
NennemanTheGame_Win64_Shipping!operator<<() >NennemanTheGame_Win64_Shipping!ParallelForImpl::ParallelForWithPreWorkInternal >() >NennemanTheGame_Win64_Shipping!UWorld::SendAllEndOfFrameUpdates() >NennemanTheGame_Win64_Shipping!FRendererModule::BeginRenderingViewFamily() >NennemanTheGame_Win64_Shipping!UGameViewportClient::Draw() >NennemanTheGame_Win64_Shipping!FViewport::Draw() >NennemanTheGame_Win64_Shipping!UGameEngine::RedrawViewports() >NennemanTheGame_Win64_Shipping!UEngine::LoadMap() >NennemanTheGame_Win64_Shipping!UEngine::Browse() >NennemanTheGame_Win64_Shipping!UEngine::TickWorldTravel() >NennemanTheGame_Win64_Shipping!UGameEngine::Tick() >NennemanTheGame_Win64_Shipping!FEngineLoop::Tick() NennemanTheGame_Win64_Shipping!GuardedMain() >NennemanTheGame_Win64_Shipping!GuardedMainWrapper() NennemanTheGame_Win64_Shipping!WinMain() >NennemanTheGame_Win64_Shipping!__scrt_common_main_seh() [d:\agent_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288] kernel32 ntdll
Thanks if anyone even gets to read this, seems those forums have died long ago.
These two occoured as well, might texture files be the cause of this?
Saw a lot of flipbooks breaking and detaching from my actors in the packaged build as well…
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION writing address 0x00000008
NennemanTheGame_Win64_Shipping!UWorld::MarkActorComponentForNeededEndOfFrameUpdate() NennemanTheGame_Win64_Shipping!UPaperFlipbookComponent::CreateSceneProxy() NennemanTheGame_Win64_Shipping!FScene::AddPrimitive() NennemanTheGame_Win64_Shipping!ParallelForImpl::TParallelForData >::Process() NennemanTheGame_Win64_Shipping!TGraphTask > >::ExecuteTask() NennemanTheGame_Win64_Shipping!FTaskThreadAnyThread::ProcessTasksUntilQuit() NennemanTheGame_Win64_Shipping!FTaskThreadBase::Run() NennemanTheGame_Win64_Shipping!FRunnableThreadWin::Run()
…
LowLevelFatalError [File:Unknown] [Line: 755] Trying to call UObject::BeginDestroy from outside of UObject::ConditionalBeginDestroy on object /Game/2DSideScroller/Characters/0bystanders/dr-zion/textures/dr-zion_still_3. Please fix up the calling code.
NennemanTheGame_Win64_Shipping!operator<<() NennemanTheGame_Win64_Shipping!ParallelForImpl::TParallelForData >::Process() NennemanTheGame_Win64_Shipping!TGraphTask > >::ExecuteTask() NennemanTheGame_Win64_Shipping!FTaskThreadAnyThread::ProcessTasksUntilQuit() NennemanTheGame_Win64_Shipping!FTaskThreadBase::Run() NennemanTheGame_Win64_Shipping!FRunnableThreadWin::Run()
I don’t know exactly what your problem is I’m afraid, but I did also have a lot of crashes myself, also with addresses which are clearly out of the application address space.
What I tracked it down to in the end was a particularly monstrous circular reference. My was to do with the save game.
I had to find the reference by end eventually, but this tool:
Pointed me in the right direction. If you have some very long chains ( more than a couple of actors referencing each other ) in the output, you may have the same problem.
Installed the plugin and indeed I got 14 circular dependencies. Fixed them but the crashes are going on.
I know that some of the actors, that had circular dependencies, are causing the game to crash, since removing them from the levels in question fixed everything.
My character has child classes, which are the chars you end up playing as. If let’s say the parent char references another actor, which references the child char, is that a circular dependency? The Plugin doesn’t say so.
Is spawn_actor_from_class causing a dependency?
What role do interfaces and common_functions play in all that? I’ve heard that interfaces are involved in some kind of workaround but so far I’ve only had trouble with them.
Did your game crash every other time or every time? (important, because mine does the latter)
Anyway thank you so much for answering in the first place, worked my ■■■ off this afternoon, hopefully this won’t be for nothing in the end.
Ok, the fact that removing them stops the problem, and they have circular dependencies does say it all really.
It’s a little hard to describe what to look for, but when I was rummaging around in the reference viewer, I came across just one link, that basically connected all of my project back into all of my project again. It was caused by having a user defined type in my save game ( as opposed to only generic variable types ).
Like I say, on the whole, circular dependencies shouldn’t matter that much, but one or two particular types WILL take you out.
Like the guy who designed the plugin says on his docs page, the answer is dispatchers and interfaces. I replaced a lot of my code in the way, but sometimes you do need ‘tight coupling’.
I went from about 350 dependencies to about 50 ( 
) and now it’s ok, because I removed the main offender.
If you can’t be bothered with figuring out how to replace everything with interfaces, there’s always this:
It means you can call and bind to global events ANYWHERE 
There are also a few other similar products ( search ‘global event’ ).
If you can get any further, maybe you can upload the critical part of your project somewhere and I’ll take a look. I recall it did take me a while before I got my head around the exact problem.
Well, there are no obvious circular refs left but i feel like there’s some more of them.
Just spent the whole day digging through my code and adding event dispatchers where I never would have thought of using them otherwise. Didn’t think they were that useful… 
That’s so strange that only now I’ve heard about circular refs, never had that explained to me by any of them countless tutorials…
The thing with interfaces is that they made it hell for me to nativize my BPs but inclusive nat does the job:D
Feels like the levels in question are loading a bit more consistently now but after every 4-8 times there’s still one or the other crash happening.
As i said I got rid of the obvious ones, I’ll have another look tomorrow and if I can’t find anything, I’ll get back to you. (And if I do, I’ll raise a glass to you :DD )
Thanks btw, even if none of us should find the error. You feel lost in these forums fairly quickly.
(ps I’m having these annoying timeouts as well-.-)
Hey!
I think nobody every talks about circular refs because generally, they don’t matter.
I think Epic has a way of compiling the blueprints that irons out any circular stuff. However, the algorithm is not perfect, and if you’ve got a real humdinger, it will still take the system out.
It sounds like you’ve got most of them.
Tell me how it goes, if you can, after the timeouts…
( BTW, I just got timed out writing that! )
Well, i don’t get it. The plugin doesn’t eitherXD
Spent some hours browsing the reference viewer but so far everything seems to be ‘linear’ if you want to call it that.
Dunno, would you mind taking a look at what’s going on?
The faceless_franky and flying_gichtel actors are causing trouble but there should be plenty more, i just don’t know which ones in particular but I’m pretty confident there is just one big ninja of an error hidden somewhere deep down in those project files, corrupting everything.
For my part, I’m absolutely clueless at this point:/
Another question, you don’t happen to know how much of a step it is to switch to c++ right? Think one has much more insight in what’s happening but I wrote some code for a linetrace yesterday and it was an absolute painXD The question is, should I git gud? 
Yep, 64bit doesn’t work either and the game doesn’t need much ram, so 32 bit is the way to go for compatibility reasons if that makes sense.
Then I get some guff about need visual studio, do you use that?..
Hey, I’ll take a look. What’s the best thing to make it crash?
Thanks so much bro
Just build it for windows, the main_menu works fine as expected but as far as I know any other map should crash with a 50±10% chance. I tried dz_level_1 without enemies and it worked. The error for sure has sth to do with what’s going on in most actors (/enemies?).
Hope those file- and variable names ain’t too distractingXD
don’t know if n_char is clean either tbh, but dz_char is for sure.
I can only package for win 32, is that right?..
usually i don’t have any compiler errors or warnings when packaging.
Well, can’t package the original at all, without a compiler apparently. No idea why that is.
So I made a new 2D side scroller project and migrated your stuff into there. You also have to copy the config folder from one project to the other.
Hasn’t crashed so far, but mind you I’m not sure what I’m doing.
I can load one level, but them I’m just stuck in it.
uuhm, i have vs installed but i havent defined any c++ classes, so that’s strange…
the one where it’s snowing? well yeah there is no level switch…
wait a sec, did you start in the main menu? just that i know, where you are, forgot which one i set as start level. (should be main_menu, but ive recently experimented with dz_level_1 and 2.
well once a level has loaded everything works fine, had only one mid level crash in one year of development, but as soon as you load a playable level with actors inside it, there might a crash coming your way
should i also have said, that ive updated the engine and migrated the stuff a couple of times? have been told unreal has quite good forward compatibility…
oh and i had to redefine custom object channels and input when i migrated, yeahXD
Well, I’ve started most of the levels several times, only had one crash, on John Do. And that was just - BANG -