0.3.34 regression (Windows, clang-cl, DYNAMIC_ARCH, NO_AVX512): access violation in dgemm_kernel_ZEN/HASWELL on AMD Zen 4/5 when AVX-512 is exposed; 0.3.33 fine

[bodono]

Summary

OpenBLAS 0.3.34 built for Windows x86-64 with clang-cl/flang, DYNAMIC_ARCH=ON, NO_AVX512=1, pthreads (the conda-forge win-64 package libopenblas 0.3.34 pthreads_h877e47f_1) crashes with an access violation inside dgemm_kernel_ZEN / dgemm_kernel_HASWELL on plain dsyrk/dpotrf calls with small matrices (dsyrk('U','T', n=55, k=165) is enough), on AMD Zen 4 and Zen 5 machines when the CPU exposes AVX-512. The same binary works on AMD machines where AVX-512 is not exposed (e.g. Zen 3, or Zen 4 VMs whose hypervisor masks it) and on Intel Xeons that do expose it. 0.3.33, 0.3.31, 0.3.29 and 0.3.27 built by the same recipe (same build-config hash) run the same reproducer fine on the same machines, so this is a regression between the 0.3.33 and 0.3.34 sources.

Reported first at conda-forge/openblas-feedstock#196; the maintainer there does not think it is a packaging problem and asked for an upstream issue.

Details

• Deterministic on an affected machine; independent of the selected core table (OPENBLAS_CORETYPE=Zen forced: same crash at dgemm_kernel_ZEN+0x6ea6; on a Zen 5 the default fallback is Haswell and it crashes at dgemm_kernel_HASWELL+0x6ea6) and of threading (OPENBLAS_NUM_THREADS=1: still crashes, earlier in the kernel at +0x16e).
• Under cdb (with _NO_DEBUG_HEAP=1) the fault is on the kernel's ret: the stack pointer and every callee-saved register hold IEEE doubles, i.e. the kernel's own frame was overwritten with matrix data.
• All runners had the same OS image (GitHub Actions windows-latest, Windows Server 2025, image 20260819.586); AVX-512 exposure was read from numpy's __cpu_features__['AVX512F'] in the same process.
• The same 0.3.34 sources built by the numpy project (scipy-openblas32 0.3.34.106.0, AVX-512 kernels included) run the reproducer fine on the affected machines, where they select SkylakeX.
• Between v0.3.33 and v0.3.34 the commits API shows no changes under kernel/x86_64; the changed areas that look relevant to a corrupted kernel frame are the level-3 locking rework (driver/level3/level3_thread_lock.c, 9363452, 298d53c, a2261f9), driver/others/memory.c, the BLAS_LOCK_DEFINED guard in common_x86_64.h, and the build-system changes (Makefile.system, cmake/arch.cmake, cmake/system.cmake, cmake/prebuild.cmake). I have not bisected.
• Side note: dynamic.c handles AMD extended families 8, 9 and 10 only, so family 0x1A (Zen 5, e.g. AMD EPYC 9V45) returns NULL and the capability fallback selects Haswell under NO_AVX512 (or Cooperlake/SkylakeX otherwise) instead of Zen.

Machines (standalone reproducer, fresh conda environments, 16 GitHub runners)

runner CPU	AVX-512 exposed	VMs	core selected	0.3.34	0.3.33	0.3.31	0.3.29	0.3.27
AMD EPYC 9V74 (Zen 4)	yes	2	Zen	crash (0xC0000005) 2/2	ok	ok	ok	ok
AMD EPYC 9V74 (Zen 4)	no	8	Zen	ok	ok	ok	ok	ok
AMD EPYC 7763 (Zen 3)	no	5	Zen	ok	ok	ok	ok	ok
Intel Xeon Platinum 8573C	yes	1	Haswell	ok	ok	ok	ok	ok

An AMD EPYC 9V45 (Zen 5) runner crashed the same way with 0.3.34 in an earlier run (only 0.3.34 was tested there; core selected Haswell).

Runs: version sweep, debugger run with the dump, forced core / thread modes.

Build configuration (conda-forge recipe)

clang-cl + flang, CMake with -DDYNAMIC_ARCH=ON -DNO_AVX512=1 -DNOFORTRAN=0 -DBUILD_WITHOUT_LAPACK=no -DNUM_THREADS=128 -DBUILD_SHARED_LIBS=on -DUSE_OPENMP=0 (see the feedstock's recipe/bld.bat). 0.3.33 from the same recipe is pthreads_h877e47f_0, 0.3.34 is pthreads_h877e47f_1.

Reproducer

# dsyrk/dpotrf/dpotrs/dgemv via ctypes on the conda-forge openblas.dll; crashes in the first dsyrk on affected machines
import ctypes, glob, os, sys
import numpy as np
binDir = os.path.join(sys.prefix, "Library", "bin")
os.add_dll_directory(binDir)
ob = ctypes.CDLL(os.path.join(binDir, "openblas.dll"))
ob.openblas_get_config.restype = ctypes.c_char_p
ob.openblas_get_corename.restype = ctypes.c_char_p
try:
    from numpy._core._multiarray_umath import __cpu_features__ as feat
except ImportError:
    from numpy.core._multiarray_umath import __cpu_features__ as feat
print("CONFIG:", ob.openblas_get_config().decode(), "| CORE:", ob.openblas_get_corename().decode(),
      "| threads:", ob.openblas_get_num_threads(), "| AVX512F exposed:", feat.get("AVX512F"), flush=True)
def by(v): return ctypes.byref(ctypes.c_int(v))
D = ctypes.POINTER(ctypes.c_double)
for (m, n) in [(165, 55), (1200, 400)]:
    rng = np.random.RandomState(0)
    A = np.asfortranarray(rng.randn(m, n)); G = np.zeros((n, n), order="F")
    b = rng.randn(n); y = rng.randn(m); info = ctypes.c_int(0)
    one, zero = ctypes.c_double(1.0), ctypes.c_double(0.0)
    ob.dsyrk_(b"U", b"T", by(n), by(m), ctypes.byref(one), A.ctypes.data_as(D), by(m), ctypes.byref(zero), G.ctypes.data_as(D), by(n))
    G[np.diag_indices(n)] += 1.0 + m
    ob.dpotrf_(b"U", by(n), G.ctypes.data_as(D), by(n), ctypes.byref(info)); assert info.value == 0, info.value
    ob.dpotrs_(b"U", by(n), by(1), G.ctypes.data_as(D), by(n), b.ctypes.data_as(D), by(n), ctypes.byref(info)); assert info.value == 0
    ob.dgemv_(b"T", by(m), by(n), ctypes.byref(one), A.ctypes.data_as(D), by(m), y.ctypes.data_as(D), by(1), ctypes.byref(one), b.ctypes.data_as(D), by(1))
    ob.dgemv_(b"N", by(m), by(n), ctypes.byref(one), A.ctypes.data_as(D), by(m), b.ctypes.data_as(D), by(1), ctypes.byref(zero), y.ctypes.data_as(D), by(1))
    print(f"ok m={m} n={n}", flush=True)
print("REPRO OK")

conda create -p .\ob -c conda-forge "libopenblas=0.3.34=*pthreads*" openblas=0.3.34 python=3.12 numpy
.\ob\python.exe repro.py

Crash dump (AMD EPYC 9V45, default core selection = Haswell, 4 threads)

rax=000001e9d8cdc200 rbx=3ff699ece033200f rcx=000001e9f7520000
rdx=0000000000000000 rsi=bfd0d1ca60b6f99e rdi=bff543da6fd24b01
rip=00007ff80b441166 rsp=000000c06efe9c38 rbp=3fd1f264f736fd5a
 r8=000001e9e7727bc0  r9=000001e9d8cdc8c0 r10=00000000000001b8
r11=0000000000000080 r12=bffaea7f2b139a9b r13=bfdb26aecf319480
r14=3fe52314bfed9253 r15=bfb0447583b403d1
openblas_115cad90a43485aceeae12031d62cd82!dgemm_kernel_HASWELL+0x6ea6:
Child-SP          RetAddr               : Args to Child                                                           : Call Site
000000c0`6efe9c38 3fe22753`b6c6084e     : bfd8660e`50759a89 3fc44d32`199d116a bfe7c85b`6fbfafdc c0026722`7d37cd7a : openblas_115cad90a43485aceeae12031d62cd82!dgemm_kernel_HASWELL+0x6ea6

Happy to run patches or a bisect build on the affected runner class; the sweep over GitHub's runner pool is automated on our side.

[martin-frbg]

Curious, I don't think any of the locking changes (which mostly collated ineffectual local locks into a global one for all level 3 BLAS) would lead to trashing a thread's stack, and a NO_AVX512 build won't (or at least shouldn't) include AVX512 kernels for anything, so a cpu exposing the capability should not be treated differently from one without. (The capabilty check in dynamic.c is also guarded with an ifdef to always return 0 when NO_AVX512 is set)

Regarding your side note - there is currently no Zen5-specific code in OpenBLAS so all such builds actually use the CooperLake target, and for non-AVX512 Zen cpus, their ZEN target is practically identical to Haswell.

[martin-frbg]

If I understand correctly that the numpy builds of the exact same version run without problems, could it be a compiler difference ?

[bodono]

Thanks for looking. On the compiler question, two facts from the packages themselves (the rendered recipes inside libopenblas-0.3.33-pthreads_h877e47f_0.conda and libopenblas-0.3.34-pthreads_h877e47f_1.conda):

• The working 0.3.33 and the crashing 0.3.34 conda-forge builds used the same toolchain: clang 21.1.8 / clang-cl and flang 21.1.8, CMake + Ninja, -DDYNAMIC_ARCH=ON -DNO_AVX512=1 -DNUM_THREADS=128 -DUSE_OPENMP=0 (only the conda build numbers of the clang packages differ, _3 vs _6). So the compiler alone can't be it; it is a 0.3.34 source change that misbehaves when built this way.
• numpy's scipy-openblas32 0.3.34 build, which does not crash on the same machines, is a different toolchain altogether: mingw-w64 gcc (rtools40, UCRT64), make BINARY=64 DYNAMIC_ARCH=1 USE_THREAD=1 USE_OPENMP=0 NUM_THREADS=24 NO_WARMUP=1 NO_AFFINITY=1 TARGET=PRESCOTT BUFFERSIZE=20, AVX-512 kernels included (it selects SkylakeX on the affected VMs). So a clang-cl-specific interaction with a 0.3.34 change is consistent with everything we see.

What changed between the tags that this path exercises, from the compare view (no commits touch kernel/x86_64; the build-system diffs are ARM/RISC-V/32-bit only):

• driver/others/memory.c: the release-info bookkeeping was reworked (local rpos, _Atomic BLASULONG lock in the memory table).
• the level-3 locking centralisation (driver/level3/level3_thread_lock.c, level3_syrk_threaded.c -69 lines, level3_thread.c) and the BLAS_LOCK_DEFINED guard around blas_lock in common_x86_64.h (clang-cl takes the C_MSVC InterlockedExchange64 branch there).

Our reproducer's first call is dsyrk, and the crash also happens with OPENBLAS_NUM_THREADS=1 (then at dgemm_kernel_*+0x16e instead of at the kernel's ret), so I would not rule out a threaded-driver-only cause, but I have not bisected. I understand the AVX-512 point and can't explain the correlation either; it is just robust in the data: same CPU model, same Windows image, the two VMs that expose AVX-512 crash 100% and the eight that don't pass 100%, so the flag may be a marker of a different VM generation rather than the cause.

If you can point at suspect commits, I can build them with the conda-forge recipe and run the reproducer on the affected runner class; the sweep over GitHub's runner pool is automated on our side. Understood on Zen 5 using the Cooperlake target in AVX-512 builds.

[martin-frbg]

The problem is I don't see any suspect commit right now - was the previous release built with the same llvm version ?
Otherwise I might imagine some weird change in the stacksize requirements for saving and restoring registers in the 8x4 dgemm kernel

[bodono]

Found it, and it is not the compiler. Two facts first:

• The compiled dgemm_kernel_HASWELL and dgemm_kernel_ZEN are byte-identical between the conda-forge 0.3.33 and 0.3.34 DLLs (first 0x7100 bytes, i.e. the whole function through the ret at +0x6ea6), so the kernel's register save/restore did not change.
• The kernel's prologue does sub rsp, 0x100 (STACKSIZE), then sub rsp, 0x3280; and rsp, -0x1000 and copies the B panel into that stack buffer, 96 bytes per k (kernel/x86_64/dgemm_kernel_4x8_haswell.S, .L12_01: // copy to sub buffer). Under WINDOWS_ABI that buffer is L_BUFFER_SIZE 128*8*12+512, i.e. sized for k ≤ 128, which is why param.h sets DGEMM_DEFAULT_Q 128 for ZEN/HASWELL under WINDOWS_ABI (256 elsewhere, with L_BUFFER_SIZE 256*8*12+4096).

What changed in 0.3.34 is kernel/setparam-ref.c (753604c "Optimize Zen 4 GEMM macro block sizes (P, Q, R)" and 5884631 "fix C89 scoping, dynamic R for memory issues, robust zen4/5 check"): a runtime block at the end of init_parameter() that, for AuthenticAMD with L2 = 1024 KB, L3 a multiple of 32 MB and CPUID.7:EBX bit 16 (AVX512F) set, overrides the table with dgemm_p = 512, dgemm_q = 512 (and sgemm/cgemm/zgemm values) on every platform. It runs for whichever core table is active (ZEN, or HASWELL on Zen 5), it has no WINDOWS_ABI guard, and it does not go through the DGEMM_DEFAULT_Q constant. So on Windows, Zen 4/5 with AVX-512 exposed now hands the Haswell/Zen DGEMM kernel k = 512 per call while its stack buffer holds 128: the B copy overruns the frame, exactly the dump above (saved registers and return address full of doubles).

That explains everything we saw: AMD only, only when AVX-512 is exposed (the CPUID.7 check; VMs that mask AVX-512 skip the block), same on the forced Zen table and on the Haswell fallback on Zen 5, single-threaded too, 0.3.33 unaffected, Intel unaffected, and numpy's build unaffected only because it includes the AVX-512 kernels and selects the SkylakeX/Cooperlake tables on those CPUs. It also means every Ryzen 7000/9000 desktop running a NO_AVX512 Windows build (conda-forge's, plus anything else built that way) hits it on any DGEMM with k > 128.

Fix options: cap TABLE_NAME.dgemm_q at DGEMM_DEFAULT_Q (128) under WINDOWS_ABI in that block, or raise the Windows L_BUFFER_SIZE in dgemm_kernel_4x8_haswell.S to match. The s/c/z kernels listed in KERNEL.HASWELL are C files without such a stack buffer, so I believe only DGEMM is affected on Windows, but I have not audited the other tables the block can hit.

I'm running a k-sweep of the reproducer on the affected runners now (n = 55 fixed, k from 64 to 256) and will post the threshold; the prediction is that k ≤ 128 passes and k ≥ ~134 crashes.

[bodono]

k-sweep confirming the mechanism: dsyrk('U','T', n=55, k) on the conda-forge 0.3.34 DLL, one fresh process per k, 16 runners (run):

runner CPU	AVX-512 exposed	core	VMs	k=64	k=96	k=128	k=132	k=136	k=144	k=160	k=200	k=256
AMD EPYC 9V45	True	Haswell	1	ok 1/1	ok 1/1	ok 1/1	ok 1/1	ok 1/1	ok 1/1	crash 1/1	crash 1/1	crash 1/1
AMD EPYC 9V74	True	Zen	1	ok 1/1	ok 1/1	ok 1/1	ok 1/1	ok 1/1	crash 1/1	crash 1/1	crash 1/1	crash 1/1
AMD EPYC 7763	False	Zen	4	ok 4/4	ok 4/4	ok 4/4	ok 4/4	ok 4/4	ok 4/4	ok 4/4	ok 4/4	ok 4/4
AMD EPYC 9V74	False	Zen	10	ok 10/10	ok 10/10	ok 10/10	ok 10/10	ok 10/10	ok 10/10	ok 10/10	ok 10/10	ok 10/10

On the two VMs where the new Zen 4/5 block fires (AVX-512 exposed), every call with k ≤ 136 passes and the crash starts at k = 144 (Zen 4, Zen table) / k = 160 (Zen 5, Haswell fallback table); with dgemm_q = 512 the driver hands the kernel the whole k, and the Windows stack buffer (128*8*12+512 bytes from BUFFER1) overflows once 96·k exceeds it plus whatever alignment slack and rsp, -0x1000 happened to leave, i.e. somewhere between k = 133 and k = 176 depending on the entry stack alignment, which is what the two thresholds show. On the 14 VMs where the block does not fire, dgemm_q stays at the Windows default 128, the driver chunks k, and every size up to 256 passes.

So the fix is either to cap dgemm_q at 128 under WINDOWS_ABI in that block (and check the sgemm_q = 512 / cgemm_q = 480 values against any similar limits), or to give the Windows build of dgemm_kernel_4x8_haswell.S the same 256-k buffer as the SysV build.

[martin-frbg]

Eek, that's insidious - and I'm fairly certain that PR only had Linux (or Unixoid systems in general) in mind. Thanks for tracking this down

[bodono]

You're very welcome, I'm glad I (with heavy AI assistance) could help.

[martin-frbg]

I'm now thinking the safest solution would be to wrap the entire addition to setparam-ref.c in ifndef NO_AVX512 so that it won't get applied to any non-Cooperlake fallback kernel (for which we probably don't even know if the increased parameters would be beneficial)