EA Staff (Retired)@Falkentyne, I honestly don't know how Easy AntiCheat works (I wasn't involved in integrating that), so I can't speak to whether it's a factor.
I do think it's related to the actual instruction sequence, and possibly it's offset in memory. I can try making a standalone test program, that's a good idea. But it's not as trivial as you might think. This function does connect with the rest of our engine, so we have to sever those connections to make a standalone program, but we have to do it in a way that doesn't change the generated assembly.
If that doesn't work, I guess I could write an assembly language file that just has this function exactly as it is in the live game, and try to have external code feed it the data expects in a way that won't crash.
Another tricky thing is that the path through this code depends on branches based on what you can see in the game. If a particular path through the code is causing the bug, you'd need to replicate the live data that causes the crash. That data can be different for every viewpoint in King's Canyon, so even replicating all of the code may not replicate the crash if we don't replicate the control flow decisions. There are things we can try to force different control flows, but it's not guaranteed to repro.
Still, it's worth a shot!
@OrioStorm Thank you very much. I would be happy to do these tests for you (after all it's what we people over on overclock.net do, spend all day running stability tests!).
I just did something very interesting on my laptop.
It is a 7820HK (MSI) laptop, and I set it to a speed which I know is unstable:
4800 mhz (cache: 4400 mhz), and 1.260v.
This laptop does not have loadline calibration so there is voltage vdroop, but there is no "live" Vcore sensor, just VID, so real vdroop is impossible to measure.
Anyway:
This laptop is highly overclocked to its max absolute limits.
At 4800 mhz, 1.260v, Apex Legends generated three CPU errors but did not crash:
1 x Internal Parity Error on thread #4
2x Cache Hierarchy Errors on threads #6 and #3. (the threads go from 0 to 7, one physical core+1 logical core, so threads 0 and 1 are for the first core, etc).
This was a 1 hour play session.
This is exactly what I would expect an unstable CPU to do.
These cache hierarchy errors are also what Realbench 2.56 and Prime95 (AVX disabled) do on my desktop when they are unstable. So this is properly expected.
Apex Legends did NOT crash however! But the fact that I got *both* internal parity and Cache L0 errors (instruction register corruption basically)--but they were corrected, means that the "Unstable" CPU is actually acting as expected.
1.265v did not generate anything but I didn't test that long enough.
The 9900K desktop, when overclocked is performing completely different however, although desktops do have a loadline calibration setting to lower CPU vdroop.
Instead of throwing any L0 cache errors in Apex, it just throws out Internal Parity Errors, or just exception error crashes Apex, while every other stress test or program (like more intensive stuff like Battlefield 5, Blender, etc) runs all day (except small FFT AVX prime95. which is a 200 amp 100C temp power virus; 1344K AVX prime is more realistic). Small FFT prime with AVX disabled also runs fine.
My gut is screaming "Microcode bug" but unfortunately, disabling loadline calibration on the desktop wouldn't work too well. as then you would need unsafe voltages to be stable with <>200mv of voltage droop. I may try disabling 4 cores (e.g. turn my 9900K into a 7700K) and then overclock and disable LLC (Loadline calibration) later, and test, but this is very time consuming.
I would enjoy doing any small code testing for you. If you have a more convenient way I can contact you or where you can post anything to test, let me know. I'm always available.
Community Manager
