Dear userbase,
I just noticed that foobar2000 64-bit crashes when using ReplayGain scanner on old computers without AVX instruction set.
This is completely unintended and caused by a bug in latest Microsoft compiler, which produces AVX opcodes even if configured not to in 64-bit mode.
If you are affected by this problem, please either stick with older foobar2000 or use 32-bit version on your computer.
I'm working on a workaround (it's not my bug...) and will revert to older compiler if necessary.
Yes,
@Peter, I am affected, that's why I still use Foobar2000 2.1 x64 (2023-12-18).
(https://i4.imageban.ru/out/2024/02/25/ef921b2d6df14d10ceb8beb722f16200.png)
Fixed version:
https://www.foobar2000.org/downloads/foobar2000-x64_v2.1.4-VS2019.exe
If nothing broke from compiler downgrade, I'll keep using VS2019 for foobar2000 2.1.x series updates.
If this is the same thing...
https://developercommunity.visualstudio.com/t/Cannot-disable-AVX-and-AVX2-in-VS-2022/10497078?space=21&scope=follow&sort=newest
... it's supposedly fixed in VS2022 17.10 - currently preview so could be tested.
Known.
I'm waiting till VS2022 17.10 before attempting any "fixes" in fb2k 2.2 series, hoping for the problem to fix itself without having to revert C++20 use in new code.
This isn't the first time stuff like this happens, as older versions of VS were known to produce SSE opcodes when configured not to.
Fixed version:
https://www.foobar2000.org/downloads/foobar2000-x64_v2.1.4-VS2019.exe
If nothing broke from compiler downgrade, I'll keep using VS2019 for foobar2000 2.1.x series updates.
Thanks! This version fixes the issue together with my intel j5005.
VS2022 17.10 installed, problem NOT fixed.
I'm afraid that, at this rate, you'll have to run old versions of various software, not just foobar2000, on machines without AVX because other apps built with new MS compiler will manifest the same problem.
On a side note, more or less same thing happened with foobar2000 v1.5.x series and SSE2 but apparently too few people care and I didn't notice until yesterday.
Yes, @Peter, I am affected, that's why I still use Foobar2000 2.1 x64 (2023-12-18).
(https://i4.imageban.ru/out/2024/02/25/ef921b2d6df14d10ceb8beb722f16200.png)
Which tool is this? I have CPU-Z but it shows the features as a single comma separated string.
This looks much nicer.
MOD: Moved /quote
You accidentally included your post inside the quote. Looks like HWiNFO (https://www.hwinfo.com/).
I'm afraid that, at this rate, you'll have to run old versions of various software, not just foobar2000, on machines without AVX because other apps built with new MS compiler will manifest the same problem.
If VS2019 works, I think you could use it for the current 2.2 series. In a previous comment you said this...
I'm waiting till VS2022 17.10 before attempting any "fixes" in fb2k 2.2 series, hoping for the problem to fix itself without having to revert C++20 use in new code.
but I don't think that's right. VS2019 should be fully C++ 20 compliant.
https://devblogs.microsoft.com/cppblog/msvcs-stl-completes-stdc20/
Indeed, VS2019 supports C++20 and compiles latest foobar2000 sources without any apparent issues so far.
Another thing, VS2022 v17.10 output crashes hard if interfaced with older vcruntime DLLs, like, ones that foobar2000 has been including until now. It looks like using latest VS2022 for foobar2000 components is a bad idea becasue they'll crash in foobar2000 install having too old runtime.
Less related thing, Apple has a loose clown in their compiler department too, their latest linker defaults to turning C++ code into something that instacrashes on Mac OS older than 12 or so, as if they couldn't obey deployment target. I'm also using old tools there because latest can't be trusted.
Yeah, I ran in to the crash when 17.10 first came out as preview a few months back.
It's specifically related to a std::mutex change documented here...
https://github.com/microsoft/STL/wiki/Changelog#vs-2022-1710
(first entry under Fixed bugs)
Seems like dynamic linking is a bad idea in general but they do provide a one line define to get around it.
AVX misuse in 2.2 series fixed, today's build is from VS2019.
https://www.foobar2000.org/changelog-win-2.2-preview
foobar2000 v2.2 preview change log
2024-05-23
Reverted to VS2019 compiler, unintended AVX requirement has been removed.
This issue of VS 2022 is reported as fixed:
https://developercommunity.visualstudio.com/t/Cannot-disable-AVX-and-AVX2-in-VS-2022/10497078?space=21&scope=follow&sort=newest
Read up the page.