code-saturne / code-saturne/code_saturne
SIGSEGV in cs_sles_solve_ccc_fv when CS_CUDA_ALLOC_DEVICE_UVM is not set (v9.1.0)
- 主要言語
- C++
- スター
- 307
- フォーク
- 102
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
## Description
`cs_sles_solve_ccc_fv` allocates its extended solver buffers using `CS_ALLOC_DEVICE` (device-only memory). Those buffers are subsequently passed to the CPU-side convergence check, which dereferences them on the host and causes a SIGSEGV.
Setting `CS_CUDA_ALLOC_DEVICE_UVM=1` before launching the solver works around the crash: it remaps `cs_alloc_mode_device` to `CS_ALLOC_HOST_DEVICE_SHARED` at initialisation time (see `cs_base_cuda.cu:777`), making the buffers accessible from both host and device.
## Steps to reproduce
1. Build code_saturne v9.1.0 with CUDA support.
2. Run any case that exercises the CUDA sparse linear solver (`cs_sles_solve_ccc_fv`) without setting `CS_CUDA_ALLOC_DEVICE_UVM`.
3. Observe SIGSEGV during the convergence check after the first solver call.
## Workaround
```bash
export CS_CUDA_ALLOC_DEVICE_UVM=1
```
Set this before invoking the solver. It prevents the crash by ensuring solver buffers are in unified/shared memory.
## Expected behaviour
`cs_sles_solve_ccc_fv` should either allocate convergence-check buffers in host-accessible memory directly, or the convergence check should use a device-to-host copy rather than a direct host dereference.
## Environment
- code_saturne version: 9.1.0
- CUDA version: 13.1
- GPU architecture: sm_75
- OS: Ubuntu (x86_64)
コントリビューションガイド
調査の方向性
cs_sles_solve_ccc_fv から開始し、その拡張 solver バッファが CPU 側の収束チェックにどのように到達するかを調査します。割り当ての動作を cs_base_cuda.cu:777 と比較し、CS_CUDA_ALLOC_DEVICE_UVM なしで CUDA ビルドを再現します。ワークアラウンドなしでも solver がセグメンテーションフォルトを起こさなくなり、既存の Unified Memory ワークアラウンドが引き続き有効であれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- cpp
- 領域
- hpc
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 48/100