Mutex.h: BREAKING CHANGE - DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR

[zsd4yr]

Describe the bug

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

Asking every single developer in the entire world to update every single copy of
msvcp140.dll
msvcp140_1.dll
msvcp140_2.dll
msvcp140_codecvt_ids.dll
vcruntime140.dll
vcruntime140_1.dll

is not an acceptable solution. This change needs to be reverted entirely or flipped to opt-in

I just spent the past several hours tracking down an obscure crash, finding it in msvcp140.dll!mtx_do_lock(_Mtx_internal_imp_t * mtx, const xtime * target) Line 102 C++ and tracking that down to a local copy of the dlls outside of the redist under https://pypi.org/project/shiboken2/

The developer community thread says as an answer

Programs should be installable to clean machines, so they should already be packaged with a VCRedist

This is exactly what manifested the issue -an old local copy.

[StephanTLavavej]

This is by design. As explained in the VS 2022 17.10 Changelog:

• Fixed mutex's constructor to be constexpr. #3824 #4000 #4339
  • Note: Programs that aren't following the documented restrictions on binary compatibility may encounter null dereferences in mutex machinery. You must follow this rule:

    When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component.

  • You can define _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR as an escape hatch.

These restrictions were documented for a reason.

This is exactly what manifested the issue -an old local copy.

Whatever's installing a freshly-compiled binary (picking up 17.10's <mutex> or newer) needs to be packaged with a freshly-updated VCRedist (in this case you can actually get away with one as old as 17.8, but no older).

I understand that this is a headache and that the Python ecosystem hasn't been following our bincompat requirements, but that's a bug in their deployment model, not in MSVC's STL.

[zsd4yr]

Hey Stephen,

I would strongly encourage you all to think more about this update model considering major customers do not follow it. I think a lot of heachache could have been saved, not only for me, but for many many others on the dev community ticket and elsewhere around github as well if, for example, this change had been opt-in instead of opt-out.

Unfortunately, what I am trying to express is that I think this python dependency did follow your instructions, and that is exactly why we were broken. Please correct me if I'm mistaken, but your guidance is to bundle the relevant redist dlls with the library or application so that they get resolved there instead of in the PATH, yes? shiboken2 did that, and it was those stale dlls alongside our upgraded tooling with the new redist installed globally that broke things for us. Perhaps I am missing something.

I used to work in DevDiv and can totally sympathize with the business case of needing a way to continue development and solutions for your customers, and I can also sympathize with designing an upgrade mechanism only to have things go another way. However, just because something is by-design, doesn't mean that design can't be improved upon, and when a sufficient plurality of your customers are cutting through the thoroughfare instead of walking on the sidewalks you built for them, you might want to consider that the paths are in the wrong place.