[BUG] `SpectralClustering` with `affinity="precomputed"` causes segmentation fault

[apiqwe]

Describe the bug

cuml.cluster.SpectralClustering causes a segmentation fault when using affinity="precomputed" with a small dense NumPy float32 affinity matrix.

The equivalent sklearn.cluster.SpectralClustering code runs successfully and returns:

[0 0 1]

However, cuML terminates the Python process with:

Segmentation fault (core dumped)

Steps/Code to reproduce bug

cuML reproducer:

import numpy as np
from cuml.cluster import SpectralClustering

a = np.array([
    [1.0, 0.9, 0.0],
    [0.9, 1.0, 0.0],
    [0.0, 0.0, 1.0],
], dtype=np.float32)

print(
    SpectralClustering(
        n_clusters=2,
        affinity="precomputed",
        random_state=0,
    ).fit_predict(a)
)

Output:

Segmentation fault (core dumped)

For comparison, the equivalent scikit-learn code:

import numpy as np
from sklearn.cluster import SpectralClustering

a = np.array([
    [1.0, 0.9, 0.0],
    [0.9, 1.0, 0.0],
    [0.0, 0.0, 1.0],
], dtype=np.float32)

print(
    SpectralClustering(
        n_clusters=2,
        affinity="precomputed",
        random_state=0,
    ).fit_predict(a)
)

Output:

[0 0 1]

Expected behavior

cuml.cluster.SpectralClustering should not terminate the Python process with a segmentation fault.

For this input, it should either return valid cluster labels or raise an appropriate Python exception.

Environment details (please complete the following information):

• Environment location: Docker
• Linux Distro/Architecture: Ubuntu 24.04 / x86_64
• GPU Model/Driver: NVIDIA GeForce RTX 4090 / 595.71.05
• CUDA: 13.2
• Method of cuDF & cuML install: conda

conda list:

# Name              Version       Build                                      Channel
python              3.14.6        h242f9ac_102_cp314                         conda-forge
numpy               2.4.6         py314h2b28147_0                            conda-forge
scipy               1.16.3        py314hf07bd8e_2                            conda-forge
scikit-learn        1.9.0         np2py314hf09ca88_0                         conda-forge
rapids              26.08.00      cuda13_260806_c2656556                     rapidsai
cuml                26.08.00      cuda13_cp311_abi3_260805_265b9da6          rapidsai
libcuml             26.08.00      cuda13_260805_265b9da6                     rapidsai
cudf                26.08.00      cuda13_cp311_abi3_260805_ff5b362d          rapidsai
libraft             26.08.00      cuda13_260805_ebf92684                     rapidsai
libraft-headers     26.08.00      cuda13_260805_ebf92684                     rapidsai
pylibraft           26.08.00      cuda13_cp311_abi3_260805_ebf92684          rapidsai
cuvs                26.08.01      cuda13_cp311_abi3_260806_25b1be43          rapidsai
libcuvs             26.08.01      cuda13_260806_25b1be43                     rapidsai
cupy                14.1.1        py314hdea9c46_0                            conda-forge
cupy-core           14.1.1        py314hcd3b49b_0                            conda-forge
numba               0.64.0        py314h8169c2f_0                            conda-forge
numba-cuda          0.30.4        py314h42812f9_0                            conda-forge
rmm                 26.08.00      cuda13_cp311_abi3_260805_42d059f1          rapidsai
librmm              26.08.00      cuda13_260805_42d059f1                     rapidsai
cuda-version        13.3           hcbadf70_3                                 conda-forge
cuda-bindings       13.3.1        py314h42812f9_1                            conda-forge
cuda-cudart         13.3.29       hecca717_0                                 conda-forge
cuda-nvrtc          13.3.33       hecca717_0                                 conda-forge
libcublas           13.6.0.2      h676940d_0                                 conda-forge
libcusolver         12.2.6.9      h676940d_0                                 conda-forge
libcusparse         12.8.2.51     hecca717_0                                 conda-forge
libcurand           10.4.3.29     h676940d_0                                 conda-forge

[jcrist]

Thanks for opening this and for the reproducible example. I can confirm this does cause a segfault.

A few additional notes from some local debugging:

• It's not a memory location issue (e.g. numpy vs cupy), our ingest pipeline is working as intended. This is likely at the algorithmic level (which resides in cuvs).
• It seems specific to input matrices <= 3x3, a 4x4 matrix doesn't see the same issue.

cc @aamijar as the person most likely to look into this further.

[dantegd]

I was actually browsing through the spectral code for an unrelated thing, and found what could be causing this.

For n_samples=3, cuML clamps the internal n_components to 1. cuVS then calculates ncv=2. However, RAFT’s Lanczos solver requires n_components + 1 < ncv < n, so this produces the invalid condition 2 < 2 < 3.

RAFT allocates V with ncv rows, but during restart it constructs and writes to V[n_components + 1]. With n_components=1 and ncv=2, that points one row past the allocation and could result in an out-of-bounds device write.

This would also explain why matrices up to 3×3 fail while 4×4 works: for 4×4, the resulting configuration is valid (2 < 3 < 4). I haven’t confirmed/ran it or tried Compute Sanitizer, but this looks like a likely cause @aamijar @jcrist

[aamijar]

Thanks @dantegd! I confirmed that your hypothesis is correct. I'm working on a fix now.