Question Burst crashes with certain processors?

We're using burst for our project and we've encountered two computers that crash whenever they perform a basic action in the game. Call stack from exception reporting:

Code (CSharp):

1. Thread 5 (crashed)
2. 0   ntdll                              0x00007ff81f48c914 ZwWaitForMultipleObjects
3. 1   KERNELBASE                         0x00007ff81c628910 WaitForMultipleObjectsEx
4. 2   KERNELBASE                         0x00007ff81c62880e WaitForMultipleObjects
5. 3   UnityPlayer                        0x00007fff82ae99bd winutils::ExternalCrashHandler::HandleCrash (C:\build\output\unity\unity\PlatformDependent\Win\ExternalCrashHandler.cpp:352)
6. 4   UnityPlayer                        0x00007fff82ae9a62 winutils::ExternalCrashHandler::HandleCrash (C:\build\output\unity\unity\PlatformDependent\Win\ExternalCrashHandler.cpp:422)
7. 5   UnityPlayer                        0x00007fff82afb4a8 winutils::ProcessInternalCrash (C:\build\output\unity\unity\PlatformDependent\Win\WinUtils.cpp:596)
8. 6   KERNELBASE                         0x00007ff81c6eb8b7 UnhandledExceptionFilter
9. 7   ntdll                              0x00007ff81f4949b3 RtlUserThreadStart$filt$0
10. 8   ntdll                              0x00007ff81f47b766 _C_specific_handler
11. 9   ntdll                              0x00007ff81f49111f RtlpExecuteHandlerForException
12. 10  ntdll                              0x00007ff81f43b474 RtlDispatchException
13. 11  ntdll                              0x00007ff81f48fc4e KiUserExceptionDispatch
14. 12  lib_burst_generated                0x00007fff81685a03 burst.Sleef_sincosf_u35@@8
15. 13  lib_burst_generated                0x00007fff81685a03 burst.Sleef_sincosf_u35@@8

We noticed that the two computers have processors in the i5-3000 series:
Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz

Is this a problem with burst and those processors specifically? Are they below min spec? Or does anyone have any thoughts on how to dig into this issue further?

 

Given how modular CPUs are these days and how small the test set is (2 computers) I find it extremely unlikely that this has anything to do with these particular CPU models unless you start seeing these issues across the entire line of Intel CPUs (of the same model, like Alder Lake, Ice Lake, etc). Basically these CPUs are all the same, they vary only in number of disabled cores, caches, features, and vary in frequency and max. power draw. But during production, modern CPUs are basically all produced to be the top of the line model (somewhat oversimplified), and then downgraded based on their electrical specs, faults during testing, and market demand.

You could try disabling Burst and test again to see if these crashes occur without burst compiled code.

If you suspect a hardware issue because the issue ONLY occurs on just these two machines I would run memtest86, possibly other system tests. To check whether they may be overheating, run Furmark + Prime95 simultaneously for 2+ hours.

 

We're currently on burst 1.8.4 - thanks for that post - do you know offhand what are the downsides to using the disable all but SSE2 workaround rather than doing the burst upgrade? We just did a round of upgrades and every time we do its a risk and comes with a fair amount of complications. Since 1.8.7 is the most recent release it makes me a little extra nervous.

As a note, we currently only have SSE2 and AVX2 currently enabled.

 

Thanks a bunch for your help!