Uncommon 0xC0000005 god-knows-where

Prepare yourself for the MOST UNEXPECTABLE AND STRANGE EXCEPTION!!!
Srsly, it’s doesn’t make any sense what i did that can cause such a strange behaviour. This happens only if i do some button combination.
First WTF (What The Function) is that stack is in uncommon state. It is not my code and it can be different to other stacks after crash(!)
Call stack:

 	UE4Editor-Core.dll!rml::internal::internalPoolMalloc(rml::internal::MemoryPool * memPool, unsigned __int64 size) Line 2059	C++
 	UE4Editor-Core.dll!scalable_realloc(void * ptr, unsigned __int64 size) Line 2425	C++
>	UE4Editor-Core.dll!FMallocTBB::Realloc(void * Ptr, unsigned __int64 NewSize, unsigned int Alignment) Line 85	C++
 	UE4Editor-SlateCore.dll!TArray<wchar_t,FDefaultAllocator>::AddUninitialized(int Count) Line 1276	C++
 	UE4Editor-SlateCore.dll!FStabilityEventLogger::GetLog() Line 94	C++
 	UE4Editor-CrashTracker.dll!FCrashTrackerEventLogger::OnHandleError() Line 53	C++
 	UE4Editor-CrashTracker.dll!TBaseRawMethodDelegateInstance<0,FCrashTrackerEventLogger,void __cdecl(void)>::ExecuteIfSafe() Line 582	C++
 	UE4Editor-Core.dll!TBaseMulticastDelegate<void>::Broadcast() Line 1030	C++
 	UE4Editor-Core.dll!FOutputDeviceWindowsError::HandleError() Line 125	C++
 	UE4Editor.exe!WinMain(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow) Line 215	C++

Second WTF is that internal bug reporter can’t even catch this. It I’ll launch engine without debugging it will crash like usual, without “sending bug report”.
Third WTF is that it happens ONLY when i double clicking LMB. LMB - is shoot, I have a bullet system, and it worked good before, but bullet were not been able to penetrate walls. Now I implemented that in a hard way (pointers to pointers to elements of two different TArray-s), so maybe this can be the problem… But it works fine if I’ll shoot slowly… That’s unexpectable at all.
Maybe it is because of overuse of operator new? There is a lot of it. Every new is completed with delete, so there is no memory leaks… possibly.
Can you look on my code and say what can cause the problems? Not where, just what. I’am a newbie in UE4, as well as newbie in using c++ in game engines, what can cause big problems because of low-level programming language. Getting of from C# where you unable to destroy program to C++ where you can calculate two plus two and it sometimes equals exception is pretty shocking :slight_smile:
BulletSlave.cpp
BulletSlave.h
BulletSystem.cpp
BulletSytem.h

It started after i renamed every delete with array after it to delete[]. Then memory leaks disappeared, but crashes appeared…

There’s a lot of dodgy stuff in your code man.

  • While Loops
  • for(;:wink:

Infinite/While loops should not be used in gameplay logic - you will run into problems.
Replace all these with either

  • Checks in the tick function, or
  • Event/Callback-based system

I’m out of my depth here, but I’ll give it a shot. Consider ABulletSystem::MakeBullet().
Now, I assume this is called from an input thread. Now, you shoot a bullet and all is fine. Now you shoot a second bullet which calls this function again, but oh dear, this thread is still busy executing the while loop from the previous bullet. I honestly don’t know what’s supposed to happen there, but I’m pretty sure it’s not going to be pretty.

I’d say replace all these loops with better logic first and check if you still have any problems.

Well, i can’t really understand why, but when i recoded MakeBullet() without while loop it works. Actually i found mistake in algorithm, this mistake not affecting workability, but making crashes. Now i’am firing 30 bullets per second and it still goes! Thanks for the shot :slight_smile:
And i should say, that ticks, input calls, even timers are using the same main thread. And what more interesting - while loop before not worked at all. On this point condition in while oftenly even not true. It was just in case.
MakeBullet():

bool ABulletSystem::MakeBullet(FVector p, FVector v, float m, bool ableToPenetrate, float loss, AController * C, AActor * A)
{
	if (nowCount == currentCount || nowCount + 1 == currentCount) return false;
	++nowCount;
	bullet[bullet[0].ItoMe].InextFree = bullet[0].InextFree;
	bullet[bullet[0].InextFree].ItoMe = bullet[0].ItoMe;
	if (bullet[0].exists) freeI = bullet[0].InextFree;
	else freeI = 0;
	bullet[freeI].BulletCreate(p, v, m, ableToPenetrate, loss, C, A, trails[freeI]);
	trails[freeI]->StartEmitting();
	return true;
}

DestroyBullet():

void ABulletSystem::DestroyBullet(int32 number)
{
	if (!(number >= 0 && number < currentCount)) return;
    --nowCount;
	bullet[bullet[number].ItoMe].InextFree = number;
	bullet[bullet[number].InextFree].ItoMe = number;
	bullet[number].Destruct();
	trails[number]->StopEmitting();
}

Oh, hell no! It happened again!

I think Access violation generally indicates you’re trying to access a property/function on a null reference. I see quite a few examples in your code where you’re not checking for null safety, e.g.

bool ABulletSystem::MakeBullet(FVector p, FVector v, float m, bool ableToPenetrate, float loss, AController * C, AActor * A)
{
	...
	trails[freeI]->StartEmitting();
	...
}

void ABulletSystem::DestroyBullet(int32 number)
{
	...
	trails[number]->StopEmitting();
	...
}

void ABulletSystem::MakeSystem(bool pure)
{
...
		{
			for (int i = 0; i < currentCount; ++i) trails[i]->Destroy();
		....
		}		
}

I would suggest you ensure that these references are not null before calling anything on them.

MakeSystem() calls once at start, so if it would fail I will not be able to even start. But it can make something wrong…

OMG, there is crash after crash, like the whole engine is self destructing. I have no idea what is going on. I had removed every new operator, as well as delete, now it crashes somewhere else, but not in avaliable .cpp files. Attempts to access 0x0000000000000000 for writing/reading, randomly crashes somewhere right in the middle where is no source code avaliable, crashes when i stopping simulation (Malloc memory write access denied, see above), not crashes at all sometimes.
THIS IS CHAOS!!! Sometimes i think that my RAM is broken! I can’t debug it! I don’t know where it is happens! I don’t know WHY
it happens! What is TBB that messing everything up? Is it legal to use new operator to non-engine types? Can I use clean C++ without using engine API?
Oh dear, one more project has been successfully ruined…
UE4 developers, where are you?! I can send you whole project, just let me know what is wrong!

SUCCESS!!! I MADE IT!!! THIS GOD DEM THING NOT CRASHES ANYMORE!!!
What happened before: started editor, started simulation for the firs time and stopped - still works, started for the second time, attempted to stop simulation - it crashed god-knows-where, where no source code avaliable. I had no idea why. Then i started to debug code deeply, created breakpoint in custom destructor of actor-type class, had got to Garbadge Collector code somehow, noticed finnaly, that ~UObject() causes crashes of unavalability of writing to the memory. Maybe class already destroyed?.. But then where?.. Wait a minute… Oh my, I’am literaly idiot. I made custom destructors! Erased them from code - now all fine! Zaebis voda, blyat, huyarilsya ob stenu pochti nedelu iz-za kakogo-to destuctora!
I think documentation needs to have rule for UObjects written with HUGE BOLD letters: "Don’t you dare creating you own destructor in UObject delivered class - it will cause inexplicable crashes, memory access violations and even more!"

1 Like