Video Example
Works:
if (OtherActor->IsA(AFPS1Projectile::StaticClass())){}
Crashes (note that it only contains outcommented lines):
if (OtherActor->IsA(AFPS1Projectile::StaticClass()))
{
// Destroy the projectile hitting it
//OtherActor->Destroy();
// Take damage
//TakeDamage(10.0f);
}
I tried it like 6x and everytime the same result. I use ctrl+z to revert the code, compile and it crashes, I put the code back in one single line, compile and it works again.
I tried restarting VS and UE4 and the entire computer but it didn’t help. How is it possible that 2 pieces of the EXACT SAME CODE but one having comments crashes the engine (reproducible)?
I made a video because I’m sure nobody would believe me otherwise.
After more testing I can only conclude that no matter what I put between those if-statement brackets, crashes the engine. Hell, even adding an else-statement to it (empty) crashes the engine. Another example that crashes UE4:
if (true) // <<< this line crashes the UE4 Editor.... how is that possible?
{
}
else
{
}
Only i can think of is that this is bug in VS compiler optimizer, it might remove the useless code where there is nothing inside “if”, but if there at least comment it tries to call a function hance the diffrence in behavior, wither way i think it’s VS compiler fault, since UE4 don’t interact with the code structure at all.
As for crash it self:
OtherActor->IsA(AFPS1Projectile::StaticClass())
is definitely the fault, one possible reason is OtherActor being null for some odd reason, try doing this OtherActor && OtherActor->IsA(AFPS1Projectile::StaticClass()) (when you use && operator if first condition fails then 2nd condition is not even checked, there for not called and won’t crash) . Always when you have a crash first thing you need to do is check logs in Saved.Log in your project directory, if crash is controlled due to detection of some problem engine leaves informatiuon about it there, if log is cut (without leaving any information) that means it uncontrolled crash (happens before any detection) and in most cases it’s either calling something on null pointer (OtherActor is null) or invalid native cast (which never gonna happen is you use UE4’s Cast function)
Comment if you finds anything in logs
Mmm it could be VS indeed. Because in C#/XNA I once also had a bug like this due to the optimizer removing code that VS assumed to be redundant while it was actually critical code that could not be removed by the optimizer. So it would compile but at runtime it would cause really weird crashes.
The change below indeed fixed it. But nonetheless OtherActor should not be NULL when colliding with the player just for having comments in my code…
OtherActor && OtherActor->IsA(AFPS1Projectile::StaticClass())
As for the log, it did indeed give a reason for crashing. But sometimes the ‘stacktrace’ (or whatever it is called) would show that it is that if-statement where the crash occurs.
Judging from the logfile below, something is bugging, be it VS or UE4. A NULL-check is a good idea but nonetheless there is a bug somewhere. It could be VS’s optimizer. Or it is UE4 or maybe even NVidia.
Log snippet of the most recent crash (PhysX error?):
[2016.04.14-19.10.40:727][ 4]LogTemp:Warning: wooi: TriggerBoxLava1.
[2016.04.14-19.10.41:229][ 63]LogTemp:Warning: Playertook damage. New HP: 90.000000/100.000000
[2016.04.14-19.10.41:355][ 78]LogTemp:Warning: end: TriggerBoxLava1.
[2016.04.14-19.10.45:227][523]LogCrashTracker:
[2016.04.14-19.10.45:232][523]LogCrashTracker:
[2016.04.14-19.10.45:232][523]LogWindows:Error: === Critical error: ===
Fatal error!
[2016.04.14-19.10.45:266][523]LogExit: Executing StaticShutdownAfterError
[2016.04.14-19.10.45:267][523]LogOutputDevice:Warning:
Script Stack:
BaseEnemy.OnHit
[2016.04.14-19.10.45:269][523]LogPhysics:Warning: PHYSX: ..\..\PhysX\src\NpScene.cpp (2946) 8 : PxScene::unlockWrite() called without matching call to PxScene::lockWrite(), behaviour will be undefined.
[2016.04.14-19.10.45:269][523]LogPhysics:Warning: PHYSX: ..\..\PhysX\src\NpScene.cpp (2946) 8 : PxScene::unlockWrite() called without matching call to PxScene::lockWrite(), behaviour will be undefined.
[2016.04.14-19.10.45:269][523]LogPhysics:Warning: PHYSX: ..\..\PhysX\src\NpScene.cpp (2946) 8 : PxScene::unlockWrite() called without matching call to PxScene::lockWrite(), behaviour will be undefined.
[2016.04.14-19.10.45:269][523]LogPhysics:Warning: PHYSX: ..\..\PhysX\src\NpScene.cpp (2946) 8 : PxScene::unlockWrite() called without matching call to PxScene::lockWrite(), behaviour will be undefined.
[2016.04.14-19.10.45:270][523]LogWindows: FPlatformMisc::RequestExit(1)
[2016.04.14-19.10.45:270][523]Log file closed, 04/14/16 21:10:45
Ok i convet to comment since my anwser is kind of invalid, i run few experiment myself
calling null pointer call condition on if without comment crashed
if (true)
{
}
else
{
}
didnt crash for me
There possibility that UE4 compile button doing something wrong, try building only using VS (hotreload will trigger anyway), try after crash to restart editor and see if it crash again, hotreload is sometimes buggy. There also possible that VS points you to wrong point where crash happens (this may happen when PDB files are broken and don’t align with code), you may try run dubugger, then you will get stack dump and we be sure that if crahs happens somewhere in engine or your code
And again check the logs that most importent part with any crash, other wise everyone is in black as much as you do
Also since you seem to be unaware, C++ is compiled to native machine code (the code that runs direcly in CPU) if somethings wrong happens in your code execution which runs direcly in CPU, OS will stop UE4 without even asking informing UE4 about it. VS compiler is reponcible for forming machine code so there is possibility something is wrong there, there is also possible that problem is in generated code by UHT (which is Unreal’s assit tool which do some extra stuff), but as i know UHT never checks cpp files.
Well you DID give me a solution to my problem so you did already greatly help me! Thanks. It’s just that I don’t know (and am curious) as to what is causing the crash exactly.
I tried both compilers both with the same result. Both crash/don’t crash depending on whether or not I add more lines of code/comments and whether or not I check for the NULL value.
I checked another ~10 logs and all show the same error as I posted earlier. All contain that critical error followed by a bunch of PhysX errors and all crash logs are identical aside from the date&time of course.
My knowledge of UE4 is almost nothing and by far not enough to even remotely debug this but I do know that the bug is not a mistake from me. So for now I will just apply your fix/workaround so I can at least continue with the project. But I will remain curious regarding the cause. ‘My chips are on the Visual Studio optimizer’ being the culprit.
I did zip the entire project just in case. It does seem to be a really nasty bug to track down as we don’t even know what program is causing it and the logfiles report a rather odd error. May not be worth our time to investigate it. Perhaps the UE4 team can if they get more reports over time. But due to it’s rarity probably won’t get any priority. bugs like these occur like once every 5 years or so.
Now this really is interesting it indeed looks like PhysX internal error, by looks of it anything what you will place in OnHit will crash. Try placeing not “if” but some function that is more neutral like:
GLog->Log("Hello World");
It will print Hello World in log, we will elimite if this has anything to do with “if”
Also try running debugger, VS debugger shows more info about crash when it happens, there will be stack dump table, stuck is order what function called what function called what function etc. function that is currently running (stack is actually CPU feature to track where to return to when specific section of code is completed (like function), but it alsovery helpful for debuging too), we will maybe know something more, do screenshot if you dont know what to do. Remember to click “Break” button when VS showed up with info that crash happened.
also never seen something like this:
Script Stack:
BaseEnemy.OnHit
There is possibility this happened in blueprint execution, do you incorporate blueprint with this class?
Ok then i will convert back to anwser if oyu think so, maybe we will solve this ^^
Just run debugger, when crash happens click “Break” and do screenshot and show me
This is just a c++ class derived from ActorComponent. It’s not a blueprint. The enemy itself obviously is a blueprint but it’s just the basic playercharacter from the 3rd person project which I added to the firstperson project with very slight modifications (removed camera, added pathfinding).
This is weird. I’m getting different results with the same code now. The code below works including the if-statement. I can not explain why the if-statement works this time. I tried both compilers and both work.
GLog->Log("Hello World");
GLog->Log("Hello World");
GLog->Log("Hello World");
GLog->Log("Hello World");
if (true)
{
}
else
{
}
Also adding:
if (OtherActor->IsA(AFPS1Projectile::StaticClass())) {}
works and the line below also works:
if (OtherActor->IsA(AFPS1Projectile::StaticClass())) { float test = 0.0f; }
But code below crashes due to a null-value:
if (OtherActor->IsA(AFPS1Projectile::StaticClass()))
{
GLog->Log("Hello World");
}
Also I noticed that sometimes compiling in the UE4 Editor gave me a successful compile. But alt-tabbing to VS and it showed me like 80 errors… It didn’t update the VS error-log. Manually compiling VS straight after completes the compile instantly and removes the errors. This could just be a GUI bug in VS and unrelated to this problem.
Also I’m surprised that “OtherActor” is a NULL value every time the enemy and the player touch. That however may be a mistake on my end somewhere. Still does not explain why the same code can crash/not crash depending on how it is written.
Ugh that character-limit from UE4 answers… anyway:
I think that:
if (OtherActor->IsA(AFPS1Projectile::StaticClass())) {} // gets removed by VS optimizer
if (OtherActor->IsA(AFPS1Projectile::StaticClass())) { GLog->Log("Hello World"); } // NOT removed by VS optimizer
So it does matter what I put in there. If it get’s optimized the code works because the if-statement never tries to use a NULL-value. When it does not get optimized the if-statement will crash because it uses a NULL value.
AActor* test = NULL;
if (test->ActorHasTag("test")){} // not optimized and crashes
So I’m getting more and more sure that my original code was bugged (due to using a NULL-value). Why it receives a NULL-value for the actor that hit it is totally unknown to me. Should not be possible for this variable to be NULL when 2 actors collide…
I did more tests and as soon as I use code that can’t be optimized (global variables, method calls, debug messages, and strangely even comments) UE4 will crash.
Attaching the VS debugger:
Exception thrown: read access violation.
OtherActor was nullptr.
My conclusion:
My code was bad because I did not check for a null value. It just happened to not crash ‘at random’ whenever the VS compiler did optimize it out. But when it didn’t, it would crash. And the PhysX error is probably a random error for using a NULL value in some strange way.
One question still remains: how can OtherActor be NULL when OtherActor is an actor (the player)?
I still don’t know how it is possible for OtherActor to be a nullptr when OtherActor is the player. But I marked it as solved because I can proceed + VS was likely to optimize it out which made my code before look valid even though it was not.
And the errorlogs, they only added more confusion due to displaying unrelated errors/warnings.