Segfault during C++ exception unwind through chipStar destructor after hipCreateTextureObject returns hipErrorInvalidValue

[pvelesko]

Platform

• Hardware: Intel Data Center GPU Max 1550 (Aurora @ ALCF)
• chipStar version: 2026.04.29
• Backend: Level Zero (CHIP_BE=LEVEL0)
• Compiler: oneAPI 2025.3
• Application: GROMACS 2024

Symptom

hipCreateTextureObject returns hipErrorInvalidValue (because zeImageCreate fails internally — filed as a separate issue). The calling application (GROMACS) checks the return code and throws a C++ exception (gmx::InternalError). The C++ exception unwind then traverses chipStar stack frames and triggers a segfault.

PBS error log:

line 28: 102030 Segmentation fault $GMX_CHIP mdrun ...

The crash is not in GROMACS code — the segfault occurs inside a chipStar destructor during stack unwinding after GROMACS throws in response to the HIP error.

Why This Is a chipStar Bug

A HIP implementation must be safe to call from a C++ application that uses exceptions. If a HIP API function returns an error code, the implementation must leave chipStar in a fully-destructible state — there must be no partially-initialized objects whose destructors access invalid memory during stack unwind.

Currently, when zeImageCreate fails inside CHIPDeviceLevel0::allocateImage, the exception thrown by CHIPERR_CHECK_LOG_AND_THROW_TABLE is caught by CHIP_CATCH and converted to a HIP error code. However, device/context objects modified before the failure may be left in a partially-initialized state. When GROMACS then throws its own exception in response to the returned error code, the stack unwind hits those partially-initialized chipStar objects, causing the segfault.

Expected Behavior

hipCreateTextureObject returning hipErrorInvalidValue should be a fully recoverable error. Any application should be able to throw and handle C++ exceptions after receiving a HIP error code without causing a crash inside chipStar. The contract of a HIP error code return is that the implementation has cleanly handled the failure — applications must be able to rely on this.

Reproduction

Same setup as the companion zeImageCreate bug:

1. GROMACS mdrun on Aurora with -nb gpu -pme gpu
2. First PBS job invocation on a fresh node
3. hipCreateTextureObject returns hipErrorInvalidValue
4. GROMACS checks the return code, throws gmx::InternalError
5. Exception unwind hits a chipStar destructor → segfault

Suggested Fix Directions

(a) Ensure allocateImage / createTexture does not leave CHIPDevice in a partially-initialized state when zeImageCreate fails. Any object that was partially modified before the CHIPERR_CHECK_LOG_AND_THROW_TABLE throw should be rolled back or placed into a valid (empty/null) state before the error is returned to the caller.

(b) Audit all CHIPERR_CHECK_LOG_AND_THROW_TABLE sites to confirm that objects are either fully initialized or not modified before the throw. Use RAII or guard objects to ensure cleanup on early exit.

(c) Consider adding a test that calls hipCreateTextureObject with invalid parameters, verifies the error code is returned, then performs normal C++ exception handling to confirm no crash occurs.

Related

The zeImageCreate failure that triggers this path is filed as a separate issue.