Segmentation Fault Introduced by PR #5220

[tetsuzo-usui]

I've encountered a potential issue in my application that appears to be related to recent changes introduced in Pull Request #5220. I am experiencing a segmentation fault under certain conditions, suggesting a possible invalid memory access.

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0  0xffffb163a917 in ???
#1  0xffffb16399a7 in ???
#2  0xffffb17c079f in ???
#3  0xbb920c in dgemv_n_A64FX
        at ../kernel/arm64/gemv_n_sve_v4x3.c:91
#4  0x170231b in dgemv_
        at /lustre/home/usui/WORK/incident/20250417_OpenBLASiha_dsyevd/OpenBLAS/interface/gemv.c:290
#5  0x16e0c7b in dlatrd_
        at /lustre/home/usui/WORK/incident/20250417_OpenBLASiha_dsyevd/OpenBLAS/lapack-netlib/SRC/dlatrd.f:252
#6  0x11e8973 in dsytrd_
        at /lustre/home/usui/WORK/incident/20250417_OpenBLASiha_dsyevd/OpenBLAS/lapack-netlib/SRC/dsytrd.f:313
#7  0x41448f in ** my application **

Environment:
OpenBLAS Version: 0241d51 (git commit hash)
Operating System: Rocky Linux 8.6
Compiler: gcc 13.3.1
CPU: A64FX
Build Flags: make DEBUG=1 DYNAMIC_ARCH=1 USE_OPENMP=1 NUM_THREADS=256

I've discussed this issue with the author of the PR, and he is looking into it. Our analysis suggests that the memory access, while invalid, does not actually affect the final numerical result (when the segfault doesn't occur). However, the segmentation fault itself is obviously undesirable. We anticipate being able to provide a fix within the next 2-3 days before the next release of OpenBLAS.

[martin-frbg]

That's unfortunate - though an intermittent segfault that does not (typically) affect the numerical result suggests that the code is reading beyond the end of data, so hopefully should be fairly easy to track down.