astc-encoder-py causes Blender crashes on specific systems

[mos9527]

NOTE: This is an ongoing investigation that does not affect the overall operability of the plugin.

astc-encoder-py crashes on my own PC (running Windows 11/10.0.26100.0), tested with

• Blender 4.2.2 LTS Release build (MSVC 2019)
• Blender 4.3 Beta Release build (MSVC 2019)

---

• Preliminary debugging (w/ PDB and offical builds) shows acquiring a mutex lock on the main thread in the codec causes a read AV:
  https://github.com/ARM-software/astc-encoder/blob/631fb04e1c4bca002a8b653f34e044dbb35b32b4/Source/astcenc_internal_entry.h#L287
• The mutex in question seems to be uninitialized, which shouldn't happen.
• I've tried to debug this with my own Debug/Release/RelWithDebugInfo build of Blender (MSVC 2022)
  (4.4 Alpha @ https://projects.blender.org/blender/blender/commit/e9298dced494)
  • And the debug/non-debug build of the C extension (MSVC 2022. Same as the distribution as it seems?)
    (https://github.com/mos9527/astc-encoder-py)
  • This did not reproduce the issue. And does in fact work.

---

Appendix: Minimal reproducible example (w/ astc-encoder-py 0.1.8 installed) in Blender Python Console:

from astc_encoder import (
    ASTCConfig,
    ASTCContext,
    ASTCImage,
    ASTCProfile,
    ASTCSwizzle,
    ASTCType,
)
config = ASTCConfig(ASTCProfile.LDR_SRGB, 4, 4)
context = ASTCContext(config)
img = bytes(b'\x00' * 4 * 512 * 512)
size = (512,512,1)
image = ASTCImage(ASTCType.U8,*size, data=img)
swizzle = ASTCSwizzle.from_str("RGBA")

# --> acquires a lock, crashes
comp = context.compress(image, swizzle)
image_dec = ASTCImage(ASTCType.U8, *size)

# --> acquires a lock, crashes
context.decompress(comp, image_dec, swizzle)

---

The initial fix is to migrate all ASTC decoding to the legacy texture2ddecoder, which does not involve synchronization primitives.

[mos9527]

Relevant SO post: https://stackoverflow.com/questions/78598141/first-stdmutexlock-crashes-in-application-built-with-latest-visual-studio

[mos9527]

Update: The release version of Blender (4.2.2 LTS in this example) loads it's own msvcp140.dll redistribution

Which is built with Visual Studio 2019, as suggested by Die

Yet astc-encoder-py (or any Python extension built with MSVC and uses MS's STL for that matter, locally or with the latest toolset (Visual Studio 2022) would require the STL lib to be up to date; Otherwise (as in this case where ~2022 header is dynamically linked with a ~2019 lib) such combinations are considered forbidden,see:

• Mutex.h: BREAKING CHANGE - DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR microsoft/STL#4978
• constexpr mutex constructor microsoft/STL#3824 (comment)
• https://github.com/microsoft/STL/wiki/Changelog#vs-2022-1710

In this case, locking std::mutex with a 2019 VC redist and a Python extension/DLL built with 2022 headers fails since the (newer) header implements std::mutex::mutex (properly) as constexpr, while the 2019 one initializes it statically, which explains the uninitialized mutex as stated by the preliminary debug report.

[mos9527]

Update: With a updated astc-encoder-py build with _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR flag (https://github.com/mos9527/astc-encoder-py/commit/5cce309d200f66f770a54856ad544308ef702a4e), this enabled the addon to work on stock relases builds of Blender.

[mos9527]

Update: Upstream has implemented their solution in K0lb3/astc-encoder-py#2