Fatal engine errors

Development Programming & Scripting
1

I’m having a crappy time with errors in engine code. While it’s pretty obvious that it’s something I’m doing, it’s difficult to say how or why I’ve caused it.

Output:

 Exception thrown at 0x000007FEDE4174DC (UE4Editor-Core.dll) in UE4Editor.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

Call stack:

 UE4Editor-Core.dll!rml::internal::LargeObjectCache::CacheBin::get(rml::internal::ExtMemoryPool * extMemPool, unsigned __int64 size, int idx) Line 102    C++    
 UE4Editor-Core.dll!rml::internal::ExtMemoryPool::mallocLargeObject(unsigned __int64 size, unsigned __int64 alignment) Line 354    C++
 UE4Editor-Core.dll!rml::internal::internalPoolMalloc(rml::internal::MemoryPool * memPool, unsigned __int64 size) Line 2046    C++
 UE4Editor-Core.dll!scalable_malloc(unsigned __int64 size) Line 2380    C++
 UE4Editor-Core.dll!FMallocTBB::Malloc(unsigned __int64 Size, unsigned int Alignment) Line 44    C++
 UE4Editor-Core.dll!operator new<TChunkedArray<FStatMessage,65536>::FChunk,FDefaultAllocator>(unsigned __int64 Size, TIndirectArray<TChunkedArray<FStatMessage,65536>::FChunk,FDefaultAllocator> & Array) Line 3358    C++
 UE4Editor-Core.dll!FStatsThreadState::UpdateStatMessagesMemoryUsage() Line 1032    C++
 UE4Editor-Core.dll!FStatsThread::Tick() Line 877    C++
 UE4Editor-Core.dll!FStatsThread::StatMessage(FStatPacket * Packet) Line 936    C++
 UE4Editor-Core.dll!TGraphTask<FStatMessagesTask>::ExecuteTask(TArray<FBaseGraphTask *,FDefaultAllocator> & NewTasks, ENamedThreads::Type CurrentThread) Line 779    C++
 UE4Editor-Core.dll!FTaskThread::ProcessTasks(int QueueIndex, bool bAllowStall) Line 539    C++
 UE4Editor-Core.dll!FTaskThread::ProcessTasksUntilQuit(int QueueIndex) Line 340    C++
 UE4Editor-Core.dll!FStatsThread::Run() Line 839    C++
 UE4Editor-Core.dll!FRunnableThreadWin::Run() Line 74    C++
 UE4Editor-Core.dll!FRunnableThreadWin::GuardedRun() Line 23    C++

Is it possible that this is actually just a bug? I’m going to start the arduous process of disabling code in my plugin to help figure it out, but any shortcuts would be appreciated.

The errors are also inconsistent. Here’s another one:

Output:

Exception thrown at 0x000007FEE0C89B46 (UE4Editor-CoreUObject.dll) in UE4Editor.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

Call stack:

UE4Editor-CoreUObject.dll!UObjectBase::IsValidLowLevelFast(bool bRecursive) Line 237    C++

 UE4Editor-CoreUObject.dll!FGCCollector::HandleObjectReference(UObject * & Object, const UObject * ReferencingObject, const UProperty * ReferencingProperty) Line 407    C++

 UE4Editor-CoreUObject.dll!UObject::AddReferencedObjects(UObject * This, FReferenceCollector & Collector) Line 1464    C++

 UE4Editor-CoreUObject.dll!FArchiveRealtimeGC::ProcessObjectArray(TArray<UObject *,FDefaultAllocator> & InObjectsToSerializeArray, TRefCountPtr<FGraphEvent> & MyCompletionGraphEvent) Line 862    C++
 UE4Editor-CoreUObject.dll!TGraphTask<FArchiveRealtimeGC::FGCTask>::ExecuteTask(TArray<FBaseGraphTask *,FDefaultAllocator> & NewTasks, ENamedThreads::Type CurrentThread) Line 779    C++
 UE4Editor-Core.dll!FTaskThread::ProcessTasks(int QueueIndex, bool bAllowStall) Line 539    C++
 UE4Editor-Core.dll!FTaskThread::ProcessTasksUntilQuit(int QueueIndex) Line 340    C++
 UE4Editor-Core.dll!FTaskThread::Run() Line 690    C++
 UE4Editor-Core.dll!FRunnableThreadWin::Run() Line 74    C++
 UE4Editor-Core.dll!FRunnableThreadWin::GuardedRun() Line 23    C++

The bizarre thing is, this is the line that’s throwing an error:

 if (*(void**)this == NULL)

…and if I add a watch for “this” it’s defined, but a lot of values in it are null:

http://i.imgur.com/eOjUeeh.png

How is that particular line causing an exception?

2

This does not need to be a bug, keep in mind crash happens when something wrong happens in code execution by CPU, and reason can be anything, not even related to UE4.

There seem to be some memory allocation issues as crash happens in malloc. Looking at the stack it seems this is some secundery thread thats crashing, do you use multithreading in your plugin? The cause of this might be in code creating thread or some memoery restrictions.

Can you explain what your plugin does? does it use mutithreading, if yes then how and what for? what functions od it use? do you use any low level memory stuff?

3

Thanks for the reply! I’m not adding any new multithreading in UE as far as I know. The plugin takes results from a DLL (that DOES run asynchronously using callbacks), waits for the controlling actor to tick, writes the results texture to a new texture package and saves it. So no real out of thread stuff is happening in UE apart from what it does itself.

Interestingly enough, it only crashes when I save the package and not always immediately. The only thing I’ve done between when it last worked and when the crash appeared is I updated to a newer version of the DLL I’m using, so I suppose it’s possible that it’s related to that although it seems unlikely. I’m new enough to C++ that I don’t know if they could interfere with each other’s memory spaces.

Also as an aside, it often crashes with an malloc() problem on quitting as well and that problem has always existed, so I wondered if I was missing something from my texture create/populate/save code, but I’m using an up to date example from an Epic dev now so it should also be OK.

Any new ideas what it might be from?

4

My guess is this is some memory issue between that library DLL and UE4, considering it’s trying to access address 0xFFFFFFFFFFFFFFFF it might be some broken pointer somewhere, then invalidated resource (because then it would have some random address). Still it seems the crash happens inside UE4 in Core module (which has most low level stuff), so it is UE4 trying to do something

Do you use UPROPERTY() on any pointer related to that DLL? If yes remove it, make UE4 not see any resource related to that DLL, copy all the data to UE4 types. Simple minimse shere of resources between that DLL and UE4

5

Nope, zero blueprint classes in the project. There are some pointers to data structures in the DLL but nothing UE depends on. They all seem to be working as expected as well.

I wonder if I’ve gone and assigned the texture I’m saving to a procedural mesh I’ve spawned. If so that might be the missing link. I’ll check it tomorrow at work, thanks for your help!

6

UPROPERTY() and other umacros is not only for blueprints, there primery function is to function and properties that will be added to reflection system, so engine see them. You always should use UPROPERTY() on UObject pointers, as engine will null those pointers when object is destroyed and you won’t have nasty invalid pointers.UPROPERTY() varable can be watched with getall or displayall commands. UFUNCTION() is required in some event bindings. Any function that requires engine awareness that does things exist requires those macros. UE4 will also manage them, so thats why i susspect this crash could orginate from, as UE4 wont do nothing to non-reflected pointers or varables. But i think only UObjects pointers are allowded to be reflected

Ok try to experiment, it’s definitly memory related UE4 trying to access something invalid for some reason.

7

Hello Antidamage,

Have you had a chance to look into what suggested? If so, were you able to find the cause of the problem? As this doesn’t seem to be a bug, I’ll be moving this question to the C++ section but I’d still like to help you solve it.

8

To be honest I don’t think his reply applies in this case. I have a couple of UObjects that handle interactions with the game engine and they have all the right macros, everything else is isolated from engine functionality.

I can’t remember what I last did but it seems to have stopped crashing for now. If it comes back I’ll reopen it again.

9

Well I’m glad to hear it’s not happening now at least. I’ve changed your comment into an answer so that I could this as resolved. Please be sure to comment here and reopen it if it happens again.

10

I recently encountered this issue, and I was able to trace it back to too much data being statically allocated in my .h / constructor.

In my case, I was able to fix it by moving a statically allocated array into a compile time constant, and I moved some static buffers from uint8 blah[] to uint8 *blah, and new’ed them up in the constructor.