[libimagequant] Segmentation fault

[radarhere]

Description / Steps to reproduce the issue

Over at https://github.com/python-pillow/Pillow, our MinGW GitHub Actions job recently showed a segfault when libimagequant is used. The job passed with mingw-w64-x86_64-libimagequant-4.3.3-1, but started failing when mingw-w64-x86_64-libimagequant-4.3.3-2 was released. That change came from 2d14aef, so perhaps this is related to cargo-c?

For good measure, I updated to libimagequant 4.3.4 in #23245, but the problem continued to occur.

I've created a minimal reproduction at https://github.com/radarhere/mingw_libimagequant. The segfault occurs in https://github.com/radarhere/mingw_libimagequant/actions/runs/13198684016/job/36845578278, but without the call to libimagequant's liq_version(), it passes in https://github.com/radarhere/mingw_libimagequant/actions/runs/13198259889

Expected behavior

No segmentation fault.

Actual behavior

Segmentation fault.

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-20348

MINGW environments affected

• MINGW64
• MINGW32
• UCRT64
• CLANG64
• CLANGARM64

Are you willing to submit a PR?

No response

[lazka]

related #23358

[lazka]

Upstream issue: lu-zero/cargo-c#443

A workaround is now in the repo: #23364 so you should be able to use it again.

I'll keep this open for now, since the underlying issue is not fixed.

[kleisauke]

For triaging purposes, does this only occur with libimagequant? rav1e is also built with cargo-c, which seems to work fine, at least with cargo-c 0.10.9 (see #23165).

[lazka]

@kleisauke I've extended the reproducer with another project that also crashes. Running avifdec in MSYS2 also segfaults in rav1e_version_full(), so rav1e is also affected. So it seems like a general issue.