I get this particularly when my framerate is low. Its happened very rarely through my project but recently it has started happening more due to a (possibly) unrelated issue lowering the framerate.
Assertion failed: IntFitsIn(In) [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Templates\UnrealTemplate.h] [Line: 174] Loss of data caused by narrowing conversion, In = -4611686018427387904
Hey there @thuynder,
Try this:
That should fix it, in case it doesn’t let me know!
@BRGTomasCalvario Uh… No. I am using VSM very intentionally. That is not a solution that is just opting out of a feature.
But that implies the bug is WITH VSM?
@thuynder Not exactly, there’s other stuff you can try to do.
Since you said it has been happening more often possibly due to a lower framerate issue, you can try to play with the Max Delta Time / Smoothed Framerate Range values.
@BRGTomasCalvario By definition, that would lower the framerate, not raise it.
There are two different kinds of frame rates. There’s “how often do I render a new picture,” and there’s “how often do I calculate a new world state.”
If the problem happens because you render a new world state too infrequently (deltatime is too large for simulation tick) then you can cap the size of deltatime in simulation with a max delta time – the engine will simply simulate twice (or more) between each rendered frame.
If the problem is in the renderer itself, then this will not work.
What I would do in this case, is to put a breakpoint on that assertion and check what the stack trace is when it fires. It may be possible to connect to the process when it hits, and debug. You’ll need to download debug symbols and source for your engine version for this to work.
Once you know what’s actually causing this delta time, you can check whether it’s a problem with your code (mis-using some API, some bad asset, etc) or an engine bug. If it’s an engine bug, you might get a clue for how to work around it, or you’ll have to figure out a way to fix it and re-build the engine yourself until Epic can roll out the next version. (Ideally, also contribute the fix back upstream!)
Unfortunately the callstack comes right from renderer. I do not believe the crash to come from simply having a low framerate, rather it is exasperating some other issue.
Assertion failed: IntFitsIn(In) [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Templates\UnrealTemplate.h] [Line: 174] Loss of data caused by narrowing conversion, In = -4611686018427387904
UnrealEditor_Renderer
UnrealEditor_Renderer
UnrealEditor_Renderer
UnrealEditor_Renderer
UnrealEditor_Renderer
UnrealEditor_Core
UnrealEditor_Core
@jwatte - alright got debug symbols… anyone know what the hell this means? I dont recognize many of these functions lol.
Assertion failed: IntFitsIn(In) [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Templates\UnrealTemplate.h] [Line: 174] Loss of data caused by narrowing conversion, In = -4611686018427387904
UnrealEditor_Renderer!UE::Math::TIntVector3::TIntVector3<__int64>() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Math\IntVector.h:104]
UnrealEditor_Renderer!FSceneCullingBuilder::ProcessPostSceneUpdate() [D:\build++UE5\Sync\Engine\Source\Runtime\Renderer\Private\SceneCulling\SceneCulling.cpp:2418]
UnrealEditor_Renderer!FComputeShaderUtils::AddPass<FSceneCullingDebugRender_CS>'::2’::<lambda_1>::operator()() [D:\build++UE5\Sync\Engine\Source\Runtime\RenderCore\Public\RenderGraphBuilder.inl:550]
UnrealEditor_Renderer!UE::Tasks::Private::FTaskBase::TryExecuteTask() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Tasks\TaskPrivate.h:504]
UnrealEditor_Renderer!LowLevelTasks::TTaskDelegate<LowLevelTasks::FTask * __ptr64 __cdecl(bool),48>::TTaskDelegateImpl<LowLevelTasks::FTask::Init<UE::Tasks::Private::FTaskBase::Init’::2'::<lambda_1> >'::13’::<lambda_1>,0>::CallAndMove() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Async\Fundamental\TaskDelegate.h:171]
UnrealEditor_Core!LowLevelTasks::FTask::ExecuteTask() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Async\Fundamental\Task.h:627]
UnrealEditor_Core!LowLevelTasks::FScheduler::ExecuteTask() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Private\Async\Fundamental\Scheduler.cpp:155]
UnrealEditor_Core!LowLevelTasks::FScheduler::WorkerMain() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Private\Async\Fundamental\Scheduler.cpp:397]
UnrealEditor_Core!UE::Core::Private::Function::TFunctionRefCaller<LowLevelTasks::FScheduler::CreateWorker'::2’::<lambda_1>,void __cdecl(void)>::Call() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Templates\Function.h:406]
UnrealEditor_Core!FThreadImpl::Run() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Private\HAL\Thread.cpp:69]
UnrealEditor_Core!FRunnableThreadWin::Run() [D:\build++UE5\Sync\Engine\Source\Runtime\Core\Private\Windows\WindowsRunnableThread.cpp:149]
Well, the good news is that this seems to happen in some debug render code, so it won’t happen in release…
FSceneCullingDebugRender_CS
Are there debugging overlays you are using that you could turn off? (I imagine many of the overlays will do some work even if they’re not on, though.)
In = -4611686018427387904
That looks like uninitialized or freed memory rather than a legitimate value to me. Is there some object creation/destruction/loading/unloading going on when this happens?
Do you only use blueprints, or do you use C++ as well?
@jwatte Release? Do you mean packaging? It is true that I’ve never seen the crash in the packaged game.
I’m on UE 5.4 since I did not mention.
FSceneCullingDebugRender_CS
This is just happening in random gameplay. I have a feeling it has to do with some character LODs but it happens just regularly enough to be a problem but not regularly enough to reproduce perfectly.
-4611686018427387904 is something like 2^62/63. Perhaps cloth “actors” are being destroyed, but nothing else should be. Don’t know much about those.
Lots of both BP & CPP. Not doing anything with the renderer in cpp, though, thats for sure.
There are multiple modes that the engine can be built in, with more or less error checking, and more or less optimization.
Release mode is the most optimization, and the least checking, and that is indeed what the packaged game typically is built with.
The editor is typically built in an intermediate mode, that includes some optimizations (so it doesn’t run slow as molasses) but also has debug checking still turned on.
If just want to Not See The Crash then downloading the editor source, and building your own version, where you comment out this one check, would probably be good enough. If you can debug with a debugger, and see who inserts this task that ends up generating bad data, then that might help discover a better solution.
If you have CPP code, then there’s always the risk that one of your CPP objects accidentally smashes some value, a use-after-free or buffer overflow or other wild pointer, which might be why this isn’t a widely reported crash. Those problems are of course usually more annoying to track down, especially on Windows where we don’t have valgrind, and especially where the problem isn’t easy to reproduce …
Not sure why it would crash but I found some performance issues with several hidden skeletal meshes that were still simulating despite being invisible. Out of sight, out of mind. Maybe something with LOD change on an invisible mesh with cloth actors/physics? Hard to say. But these SKs were indeed set to in editor only as they were for visualization…
