Saber Trails Missing on Release Builds

[Futuza]

For some reason saber trails randomly disappeared. However, this does not happen on debug builds, release with debug information builds, or on Mint, just Windows release builds when either /O2 or /Ox speed optimizations are enabled in the MP Client project.

Basically what's happening is, in cg_players.cpp

You have this check that sets the actual saberTrail drawing:
if ( cg.time > saberTrail->lastTime + 2 || cg_saberTrail.integer == 2 ) // 2ms

which is getting skipped because saberTrail->lastTime is set to some high integer value (eg: 118677726 - its never the same number, just on the high end, probably just some random garbage value from not being initialized.)

Anyway to fix it, I just added an explicit set when switching weapons (in CG_CheckPlayerG2Weapons() of cg_weapons.cpp:

cgs.clientinfo[ps->clientNum].saber[0].blade[0].trail.lastTime = cg.time; //prevent undefined behavior: explicitly set sabertrail timer

That seems to have worked, but am not sure if the issue is really fixed or there's an underlying problem that got missed. Trying to do more testing to make sure I didn't miss anything before I push. Need to try it on an AMD CPU on linux as well, maybe its just a really weird AMD bug.

[Futuza]

Fixed? with 465c853

[Futuza]

Reopening because in 465c853 I just added a set whenever the weapon switches to saber. So its more of a band-aid fix and doesn't actually find out the real why behind why this undefined behavior is happening.

Also discovered that if I use all debug binaries, except jkgalaxies.x86.exe (being the only release problem) it will still happen. As well as the inverse: using all release binaries, with a debug jkgalaxies.x86.exe means that the issue doesn't happen, so the root cause of saberTrail->lastTime not getting set to something valid/updated is likely happening before it ever gets to cgame and instead likely has its root cause occurring in the MP Client module (jkgalaxies.x86.exe, not in client game as you might expect).

I was also not able to replicate this on Windows 10 while using an Intel processor, so it might be processor specific (effects only AMD?), but possibly might be a difference between Windows 10 and Windows 11 or just be very specific to my machine's memory addressing and have nothing to do with OS or processor.

Daggo suggested trying to run with ub (undefined behavior) checks. And to try out the various sanitizers.

Razor suggested that because it's only ever set to cg.time there must be a memory corruption (write past bounds, aliasing) on data, or we're looking up an out of bounds saberNum, bladeNum, etc. Says I could probably find it with a data breakpoint on cgs.clientinfo[clientNum].saber[saberNum].foo when it's written out of value range.

While I'm not positive I will be able to do that with optimized release builds (as putting in debug info makes the bug not happen), I have a suspicion that the out of bound lookup is probably closer to why it is happening and will look into that more closely.