[{"content":"Referencing PR \u0026ndash;\u0026gt; PR #174009, altough there were few changes, made afterwards by the reviewers. Whenever we write tensor[0] in Python, it feels like magic. But under the hood, PyTorch has to route this operation through a massive C++ dispatching engine to figure out if this should run on a CPU or a CUDA GPU\u0026hellip;\nThe Bug: Empty Indices Crashing index.Tensor The issue behind this PR was deceptively small: torch.ops.aten.index.Tensor(t, []) could crash instead of failing cleanly when the index list was empty. In other words, PyTorch was being asked to perform tensor indexing with no actual indices, and one of the internal code paths did not defend itself against that case.\nThat sounds like a corner case, but it is exactly the kind of corner case that matters in a system like PyTorch. Indexing is one of the most heavily used operations in the entire stack, and even a tiny inconsistency can surface in surprising places, especially once you start mixing Python frontend code, ATen internals, and backend-specific behavior.\nTracing the Dispatch: Python to ATen When you write something like x[0] in Python, the operation does not stay in Python for long. It is lowered into ATen, PyTorch’s internal tensor library, where the framework decides how to interpret the indexing request and which backend should handle it.\nThat path has to answer a lot of questions:\nIs the index list valid? Are we doing basic or advanced indexing? Do the indices describe a contiguous subspace? Should the implementation materialize any optional indices first? The bug in this PR lived in that validation layer. The problem was not really about a specific device or dtype. It was about what happens when the list of indices is empty and the internal helpers assume there is at least one meaningful tensor to inspect.\nThe Solution: Fixing IndexingUtils.h and TensorAdvancedIndexing.cpp The PR made two functional changes in the C++ code and one regression test in Python.\nFirst, IndexingUtils.h was updated so that the helper that checks whether the indexed tensors form a contiguous subspace handles an empty set safely. That is the kind of guard that looks boring in isolation, but it is exactly what keeps an internal helper from wandering into undefined behavior when the input is degenerate.\nSecond, TensorAdvancedIndexing.cpp now checks the meta path for an empty index list and raises a clear IndexError with the message at least one index must be provided. That is the right failure mode here: fail early, fail explicitly, and fail in a place that tells the caller what is wrong.\nThird, the Python test suite gained a regression test that exercises the exact empty-index call:\nwith self.assertRaisesRegex(IndexError, \u0026#34;at least one index must be provided\u0026#34;): torch.ops.aten.index.Tensor(t, []) That test is doing more than checking an error message. It locks in the contract so the bug does not quietly return later after some unrelated refactor.\n","permalink":"https://tripathiji1312.github.io/posts/pytorch-aten-dispatch/","summary":"How I fixed a crash in PyTorch\u0026rsquo;s ATen C++ layer when tensor indexing receives an empty index list — tracing the dispatch from Python through to IndexingUtils.h and TensorAdvancedIndexing.cpp.","title":"Deconstructing my PyTorch ATen PR: What happens when you index a Tensor?"}]