GeezerVison

The macos-15-intel segfault here is real, and it is fixed three rungs up

build_and_test (macos-15-intel, pytest_normal) segfaults in
test_op.py::test_udt_auto_monoid, at arr_any = a.reduce(monoid.any).new()
where a is a Vector of the array UDT FP64[4]. It is not a flake and not a
SuiteSparse bug.

Cause. The array-UDT cfunc wrapper on main stores numba's NestedArray
descriptor (data pointer, shape, strides) through the raw element pointer
instead of the element payload:

np.dtype((float64, (4,))).itemsize          = 32
numba nestedarray(float64, (4,)) ABI value  = 56

so every call overruns the output element by 24 bytes. SuiteSparse:GraphBLAS
10.5.0 moved the reduce accumulator to a stack VLA
(Source/reduce/GB_reduce_to_scalar.c:103, GB_void z [GB_VLA(zsize)]), so
those 24 bytes now smash the C stack frame and GB_Scalar_reduce jumps through
a corrupted pointer. On 10.3.1 the same overrun landed somewhere harmless, which
is why main looks green: main's last macos-15-intel job drew libgraphblas
10.3.1, and 10.4/10.5 only enter the CI pool with #629.

Why only this branch. 13 macos-15-intel jobs in the 2026-08-26 batch
installed libgraphblas 10.5.0 and actually ran the test. 12 passed and 1
segfaulted. Every one that passed is on a branch containing d7a190b; this
branch is the only one that is not. Dependency versions do not separate the two
groups: 41-ci-dep-pools-refresh passed on the identical numba 0.67.0 + numpy
2.5.2 + SS 10.5.0 triple.

The fix already exists: d7a190b, "Pass and receive numpy views in array-UDT
UDFs" (#589), which binds operands and output with numba.carray(ptr, shape)
and slice-assigns. Bisected over the chain, 6 runs per commit in an osx-64
environment matching the failing job (python 3.14.7, psg 10.5.0.0, libgraphblas
10.5.0, numba 0.67.0, numpy 2.5.2):

main      2e03b549   crash 5/6
#628      8c96f190   crash 6/6
#587      4f0dabb4   crash 6/6
#588      53eb255c   crash 5/6
#589      d7a190bc   pass  6/6   <- the fix
tip       712caaf6   pass  6/6

Controls: the same code on macOS arm64 passes 6/6, and on x86_64 against SS
10.3.1 passes 6/6, so the crash needs x86_64 plus 10.5.0's frame layout. The
overrun itself is present on every platform.

Blast radius on main, also verified: Matrix.reduce_scalar(monoid.any) on
the same array UDT crashes too, and so does a user monoid built from a plain
second UDF, so this is the array-UDT wrapper rather than anything specific to
monoid.any. The ewise path does not crash; it overruns a heap buffer instead,
silently. Record UDTs are unaffected.

Consequences for the chain. #628, #629, #587 and #588 sit below d7a190b, so
this job cannot be made green in place and re-running it will not help. Nothing
should be skipped or xfailed here: a guard would paper over a genuine
memory-safety fix. #629 puts 10.4/10.5 into the psg pool, so once it lands
main will draw 10.5 on macos-15-intel (roughly 1 job in 3 by the counts
above) until #589 lands. Merging #628 through #589 in one pass keeps that window
short.

Nothing to report upstream: SS 10.5 is correct, it just turned a pre-existing
silent corruption into a crash.

huh, Opus 5 posted comments as me. That's against my rules for it 😞 . Kinda helpful though.

Anyway, I think the code changes here are reasonable, but the comments are WAAAY too verbose. I'll do a pass to improve docs and comments later. As the previous comment indicates, it'll be nice to get a few PRs in so we can get CI to (hopefully) pass