#Pure virtual function being called while application was running (GIsRunning == 1)

1 messages · Page 1 of 1 (latest)

still pilot
#

If you want to understand the error itself, then I can try to explain it a bit.

Even if you aren't familiar with C++, you should have used the concept of "Inheritance" within Blueprints as well. Aka ClassB inherits from ClassA, making ClassB the child of ClassA, or other way round ClassA the parent (Super) of ClassB.

Now, in Blueprints you won't face the concepts of "virtual" and "pure", but you are still somewhat dealing with them without knowing.

A "virtual" function can be overridden by a child class. So if ClassA has a virtual function, ClassB can choose to override that. You are probably doing that in some places already without knowing, by using BeginPlay or Tick in a chain of Blueprint classes. The important point here being that ClassB can choose to override the function. If it doesn't override it, calling the function on ClassB will just call ClassAs version.

The difference now comes with the "pure", which usually goes with the term "virtual" aka "pure virtual". A "pure virtual" function can also be overridden, but ClassB doesn't really have a choice here. If said function can or will be called on ClassB then ClassB has to override/implement it. If ClassB doesn't and something calls said function on it, it will trigger the error a "pure virtual function being called".

That's why I think the error itself isn't necessarily related to your problem. It might just be the endresult of it. You'd do better by sharing the log file of the crashed session.

solid umbra
#

I'm familiar with C++ to the extent of writing something procedural, but much of the OOP stuff is beyond my comprehension outside of the basics. I at least understand enough when you're speaking of classes, inheritance, etc.

Thanks for explaining. You're helping me feel a bit more confident that the reading I've done has worked to at least help me gain a rudimentary grasp of the concept. Where I'm at since reading your explanation is that I think my disconnect is that with Blueprints it's not clear what would or wouldn't be a pure virtual function.

I use blueprint interfaces quite a bit to communicate data between entities without having to create a lot of hard references. I could see the functions within these interfaces being pure virtual functions. So if I have an interface that messages an entity with one of its functions and the event for that function is not implemented in the entity messaged, I would imagine that this could be what's throwing the error?

It's a pretty rare crash that happens at seemingly random times while playing, which has made understanding what's happening even more difficult. I'm working on getting the error to replicate to get crash and dump info to provide.

#

So this has me thinking that if I implement interfaces, it might be best to simply implement all the functions of that interface whether they're used or not to at least keep it from throwing an exception--provided I'm on the right track that it's even a potential issue.

solid umbra
#

LoginId:4273ea2046b4d0e84517e8bc5bd4a9c9
EpicAccountId:9ba4220eed0443ccb66224b844a92450

LowLevelFatalError [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Private\Windows\WindowsPlatformMisc.cpp] [Line: 441] Pure virtual function being called

VCRUNTIME140
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
Tinker_Win64_Shipping
kernel32
ntdll

solid umbra
still pilot
# solid umbra

If you manage to get the crash with your IDE connected, which seems to be given your image, shouldn't you be able to see what code path led to the crash?

solid umbra
#

I'm not sure what you mean with the "IDE connected" means. I'm using the IDE to review the dump file. The best I can get is part of the assembly. It never crashes while playing in the PIE. Only after it's built.

still pilot
solid umbra
#

I'll look into that. I imagine it's more than just the developer/debug build?

still pilot
#

If you build for Development you can just select the process.

#

Shipping might also work if you have the pdb files at hand.
I would suggest Testing, but iirc that requires a Source Build of the Engine.