Notable breaking change in MSVC toolset vc143

[Alex Fuller]

Hi all,

I had a recent discovery while building packages for windows and thought I'd share it here as it's quite a doozy and something that can surprise you, especially for vfxplatform 2023/2024 and using a supported MSVC compiler.

https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660

I discovered this one by building OpenImageIO/MaterialX with MSVC 14.38.x (using VS 2022 17.13.1) and having an access violation with a simple mutex lock when using a python interpreter in a DCC application built against 14.34.x vfxplatform-2024 spec, and sure enough it is exactly the issue that the URL points to.

Now the approach Microsoft advises is to make sure to match the compiler as best as possible or at least use an older version to something that you plan to link to (like a DCC application) or at least bundle your application with the most recent vcredist package however "Visual Studio 2022v17.6 or later" I think is a little too loose here and host applications or random python pip packages may bundle variants of the runtime that can be out of your control to replace and hence crash if it encounters something that was built with a later compiler (despite being in the same vc143 toolset).

My thoughts are if you build for vfxp 2023/2024 and you use a compiler newer than 14.38.x and plan to link with something older, make sure to pass the following preprocessor define to avoid the issue:

_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR

Which I think should be something to note on the main page.

Kind regards

-Alex

[Larry Gritz]

Hi, Alex, thanks for this.

I'm not a Windows dev, so my knowledge of this is really minimal. Since it's hard to control which mix of compilers an end user will use to compile our libraries versus their app, etc., is your advice that it's best for us to add this definition to the internals of all of our libraries? Is there any significant downside to just doing it all the time, or should we try to predicate it on the compiler version?

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/c1b93521-82e7-4528-98be-6335264f3fedn%40googlegroups.com.

--
Larry Gritz
l...@larrygritz.com

[Pierre Jasmin]

Looks like latest updates of Visual Studio (from version 2022 v17.10() has an ABI breaking change with regards to std:mutex according to co-pilot.
Perhaps even if you make sure you have the latest vcdist if another dll does not, app will crash
Not too aware and might not be too useful here as we still use the native processthreadsapi.h for threading here on windows, and I know some folks who uses TBB (now part of OneAPI) for that which I don't think would be affected by that. 

_disable_constexpr_mutex_constructor - Search

And according to Google AI overview, there is no effect on performance to disable that, just increases a tiny bit the initialization time (one time) against making -pedantic C++ safety club folks happy :)

https://www.google.com/search?q=_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR+effect+on+performance&rlz=1C1UEAD_enUS1139US1139&oq=_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR+effect+on+performance&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQIRigAdIBCDgzNjVqMGo0qAIAsAIB&sourceid=chrome&ie=UTF-8

So seems that flag should be defined by default with a doc note.

[Alex Fuller]

Hi Larry,

My thoughts would be to have this pre-processor on for vfxplatform 2023 and 2024 as the python interpreters I've seen out in the wild (Maya 2025, Katana v8.0, Houdini 20.5) tend to use an older than 14.38.x compiler and would run into this issue. Maya 2026 and Houdini 21 are using 14.38.x and 14.42.x respectively and are vfxplatform-2025, I suspect other DCCs aiming for CY2025 would use a more recent compiler also.

I saw the Blender developers discovered this also and are applying this pre-processor as well: https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4641 I'm not really sure if there's downsides having this always-on.

Just to note we've found other issues outside of this one when using an older vcredist, odd things like some image formats reading but not writing out of OpenImageIO so we're now just copying over the more recent vcredist .dll collection over the top of the older ones we've encountered.

Cheers
-Alex

Btw I think this group is a bit heavy-handed in the spam deletion, my previous message got eaten up - hopefully this one doesn't...

[Larry Gritz]

OK, I can paper over this on the OIIO side: https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4914

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/25ce4c8b-626f-4920-804e-473d39868a16n%40googlegroups.com.