[Bug]: SIGSEGV at multi-rank iris.iris() init on mixed-architecture AMD GPUs
Maintainers usually reply within 4 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 40/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, distributed-systems
Research direction
The crash occurs in iris/host/distributed/helpers.py at line 321 in distributed_barrier, called from setup_fd_infrastructure. Start by examining the barrier implementation in torch/distributed/distributed_c10d.py line 5230. Run a minimal test with HIP_VISIBLE_DEVICES to isolate mixed-architecture effects. Check for device context creation or IPC queries before the barrier. The goal is to reproduce the segfault and understand why it only happens with heterogeneous GPUs.
Written by the indexing model from the issue text.
Description
Describe the bug
iris.iris(heap_size) segfaults (SIGSEGV) at multi-rank initialization, before
any kernel is launched, on a machine with three AMD GPUs of different
architectures. Single-rank works.
To Reproduce
On a box where torch.cuda.device_count() == 3 and the devices are
mixed-generation:
python tests/run_tests_distributed.py tests/unittests/ --num_ranks 2 -x
Result: one rank dies with Signal 11 (SIGSEGV), the surviving rank is torn
down with SIGTERM. --num_ranks 1 passes 84/84 in test_empty.py.
Stack trace / error message
Fatal Python error: Segmentation fault
Current thread 0x00007ff10c2e6740 (most recent call first):
File "torch/distributed/distributed_c10d.py", line 5230 in barrier
File "torch/distributed/c10d_logger.py", line 83 in wrapper
File "iris/host/distributed/helpers.py", line 321 in distributed_barrier
File "iris/host/distributed/fd_passing.py", line 236 in setup_fd_infrastructure
File "iris/host/memory/symmetric_heap.py", line 169 in __init__
File "iris/host/iris.py", line 115 in __init__
File "iris/host/iris.py", line 1390 in iris
Expected behavior
iris.iris() initializes at 2+ ranks on mixed-architecture AMD GPUs, or fails
with a diagnosable error rather than a segfault.
Environment
- OS: Arch Linux / CachyOS, kernel 7.2.6-1-cachyos
- ROCm: 7.14 (torch reports
hip: 7.14.60850) - torch: 2.12.0+rocm7.14
- triton: 3.7.1
- iris: main @ 5b46b8e
- GPUs: RX 9070 XT (
gfx1201) + Vega Frontier Edition (gfx900:xnack-) +
integrated Radeon (gfx1036) — three generations in one box torch.cuda.device_count()→ 3
Additional context — why I suspect it is the mixed-arch set, not generic multi-rank
Three observations, in order of strength:
-
A bare
torch.distributedtest with no iris involved passes. Two
processes,init_process_group("gloo"),dist.barrier(),
destroy_process_group()— all clean. So the process group itself forms and
barriers fine at this PyTorch version. The crash is specific to iris's
initialization path, or to a resource iris allocates during it. -
The crash is immediately after a plain
dist.barrier()(helpers.py:321),
insidesetup_fd_infrastructure— i.e. before the dmabuf/fd mesh logic that
the surrounding code is really about. That makes the barrier itself look
like the trigger surface rather than a victim of later corruption. -
All three ranks default to device ordinal = rank, so rank 0/1/2 land on
gfx1201,gfx900, andgfx1036respectively. If any per-device context
(or a peer-access / IPC capability query) is created before the barrier,
a heterogeneous set is the obvious place for a driver-level fault — and
homogeneous CI hardware would not surface it.
I have not been able to bisect further than this locally. If it is useful I am
happy to run a targeted probe against any specific hypothesis (e.g. forcing
same-arch device selection via HIP_VISIBLE_DEVICES, or stubbing the
setup_fd_infrastructure barrier) — just say which is most informative.
I am filing the docs/example-test fixes separately in a PR; this issue is the
blocker that stopped me from validating those end-to-end at >1 rank.
- Dominant language
- Python
- Stars
- 202
- Forks
- 52
- Avg merge
- 6d 1h
- Merged PRs (30d)
- 18
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ROCm/iris
-
benchmarks bug examples iris test
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 4 days
-
bug examples invalid iris
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 4 days
-
iris python test
Difficulty 3/5 Half a day Newbie friendliness 58/100
Maintainers usually reply within 4 days
-
iris
Difficulty 5/5 Over a week Newbie friendliness 15/100
Maintainers usually reply within 4 days
-
benchmarks gluon iris
Difficulty 5/5 Over a week Newbie friendliness 30/100
Maintainers usually reply within 4 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
common-workflow-language/cwl-utils#477 ·
Maintainers usually reply within 1 day
-
Add dependabotOpenfeat
Difficulty 2/5 Under an hour Newbie friendliness 72/100
open-nudge/opentemplate#204 ·
Maintainers usually reply within 1 day
-
github-stale-ci-pr-closer: KV state is double-wrapped, never persists, and hits the depth-32 limitPossibly taken @VascoSch92 claimed this today. Openpriority:medium ready-for-dev
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
OpenHands/extensions#781 ·
Maintainers usually reply within 1 day
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
curriculum documentation quality
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
githubnext/gh-aw-workshop#4638 ·
Maintainers usually reply within 1 day