[BUG]: tileiras SIGSEGV on aliased advanced-index load/store around reduction or matmul
@blinxt y travaille déjà.
Depuis le 7/8/2026.
Évaluation
Cette issue n'a pas encore été évaluée.
Description
cuTile Python version
1.5.0. Both examples also fail with 1.4.0.
CUDA Toolkit version
13.3 (tileiras V13.3.36)
Which installation method does this occur on?
Pip
Describe the bug
tileiras terminates with SIGSEGV for small kernels that load through
load_advanced_indexing, perform a reduction-like operation, and write back to
an aliased slice through store_advanced_indexing. A width-32 tile and a single
row are sufficient. The crash occurs during compilation, before launch.
I found two forms in separate QR kernels: one uses ct.sum, while the other uses
a 1x1 by 1x32 ct.matmul. Both reduce to tiny standalone examples and have the
same native failure signature. I grouped them because their isolated boundary is
the same aliased advanced-index load/store path. I expected each kernel to
compile, or to receive a source diagnostic if this alias pattern is unsupported.
Minimum reproducible examples
Reduction form:
import torch
import cuda.tile as ct
@ct.kernel()
def kernel(source):
row = ct.arange(1, dtype=ct.int32)
matrix = ct.load_advanced_indexing(
source, (ct.Slice(0, 1), row, ct.Slice(0, 32))
).reshape((1, 32))
result = ct.sum(matrix, axis=1)
ct.store_advanced_indexing(
source,
(ct.Slice(0, 1), row, ct.Slice(0, 1)),
result.reshape((1, 1, 1)),
)
source = torch.empty((1, 1, 32), device="cuda")
ct.launch(torch.cuda.current_stream(), (1,), kernel, (source,))
Matmul form:
import torch
import cuda.tile as ct
@ct.kernel
def kernel(matrix, right):
row = ct.arange(1, dtype=ct.int32)
output = ct.load_advanced_indexing(
matrix, (ct.Slice(0, 1), row, ct.Slice(0, 32))
).reshape((1, 32))
left = ct.ones((1, 1), dtype=ct.float32)
output -= ct.matmul(left, ct.load(right, (0, 0), shape=(1, 32)))
ct.store_advanced_indexing(
matrix,
(ct.Slice(0, 1), row, ct.Slice(0, 32)),
output.reshape((1, 1, 32)),
)
matrix = torch.empty((1, 1, 32), device="cuda")
right = torch.empty((1, 32), device="cuda")
ct.launch(torch.cuda.current_stream(), (1,), kernel, (matrix, right))
Run either script in a fresh compiler cache. Crash dumps are disabled only to
avoid the separate masking error reported in #92.
run=$(mktemp -d)
CUDA_TILE_CACHE_DIR=off \
CUDA_TILE_TEMP_DIR="$run" \
CUDA_TILE_ENABLE_CRASH_DUMP=0 \
python repro.py
Relevant log output
Both forms report:
subprocess.CalledProcessError: Command '['/usr/local/cuda/bin/tileiras',
'/tmp/.../kernel....bytecode', '-o',
'/tmp/.../kernel....cubin', '--gpu-name', 'sm_120',
'-O3', '--lineinfo']' died with <Signals.SIGSEGV: 11>.
cuda.tile._exception.TileCompilerExecutionError: Return code -11
Unknown location
Directly invoking tileiras on either emitted bytecode exits 139 and produces no
cubin. Each example failed in two independent cold runs with cuTile Python 1.4.0
and once more after switching the import to 1.5.0.
Environment
OS: Ubuntu 22.04.5 LTS, Linux 6.8.0-90-generic x86_64
GPU: NVIDIA RTX PRO 6000 Blackwell Server Edition, compute capability 12.0
Driver: 580.126.09
CUDA toolkit: 13.3; nvcc 13.3.33; tileiras V13.3.36
Python: 3.13.14
PyTorch: 2.12.0+cu130 (bundled CUDA runtime 13.0)
cuTile Python: 1.5.0; also reproduced on 1.4.0
CPU: AMD EPYC 9355, 16 vCPUs
Other details
These reductions cover three original compiler crashes:
_partial_dots_512(ct.sumform);_apply_wy_rows_512with an 8-column panel (ct.matmulform);_apply_wy_rows_512with a 16-column panel (same reduced form).
The following controls compile successfully:
- width 16 in place of width 32;
- advanced-index load followed by a normal store to another tensor;
- normal load followed by an advanced-index store;
- advanced-index load and store using distinct tensors;
- an aliased width-32 advanced-index load/store with only elementwise addition.
This is why the examples retain both aliasing and a reduction or matmul, while
removing all QR-specific logic, large tensors, and multi-block launch dimensions.
Contributing Guidelines
- I agree to follow cuTile Python's contributing guidelines
- I searched the open bugs and found no duplicate for this report
- Langage dominant
- Python
- Étoiles
- 2.2k
- Forks
- 155
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de NVIDIA/cutile-python
-
[BUG]: check_dtype_support rejects family-conditional (sm_XXXa) gpu_code targetsPeut-être pris @sylvesterkaczmarek l’a pris il y a 30 jours. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
NVIDIA/cutile-python#105 · 2 commentaires ·
-
nvidia-runners
Difficulté 2/5 1-3 heures Accessibilité débutants 25/100
NVIDIA/cutile-python#108 ·
-
[BUG]: FFT sample launches `Batch` blocks that each process the full batchPeut-être pris @AntonOresten l’a pris il y a 138 jours. Ouvertebug status: needs-triage
Difficulté 3/5 1-2 jours Accessibilité débutants 68/100
NVIDIA/cutile-python#102 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 68/100
NVIDIA/cutile-python#101 ·
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
NVIDIA/cutile-python#97 · 1 commentaire ·
Toutes les issues de NVIDIA/cutile-python
Issues similaires
-
feedback simulation workshop
Difficulté 2/5 1-3 heures Accessibilité débutants 73/100
githubnext/gh-aw-workshop#4455 ·
Les mainteneurs répondent en général sous 1 jour
-
Triage 🩺
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour
-
[BUG] Container scenario crashes without expected_recovery_time, kube DNS example uses retry_waitOuverteneeds-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 77/100
krkn-chaos/krkn#1627 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
NousResearch/hermes-agent#136483 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour