Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions sycl/source/detail/scheduler/scheduler.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -293,18 +293,18 @@ bool Scheduler::removeMemoryObject(detail::SYCLMemObjI *MemObj,
// No operations were performed on the mem object
return true;

#ifdef _WIN32
// If we are shutting down on Windows it may not be
// safe to wait on host threads, as the OS may
// abandon them. But no worries, the memory WILL be reclaimed.
// If we are shutting down it may not be safe to wait on in-flight work.
// On Windows the OS may have abandoned host threads. On any platform the
// adapters/contexts may already be partially torn down by early shutdown
// (e.g. the HIP runtime segfaults when synchronizing on an event whose
// stream/context has been released). During shutdown host memory is not
// written back either (see SYCLMemObjT::updateHostMemory), so waiting serves
// no purpose here and the memory WILL be reclaimed as the process exits.

@KseniyaTikhomirova KseniyaTikhomirova Jul 21, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK on Linux we were able to correctly shutdown SYCL RT and release its resources. This change disables proper resource release on Linux (on Windows due to thread's management it was disabled by default).
Could you please clarify what exact resources are released in unexpected order? And callstack where it happens.

@KseniyaTikhomirova KseniyaTikhomirova Jul 21, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cperkinsintel could you please provide your opinion about this change? I found that this test was disabled for HIP ~5 years ago, I assume that there are some static vars in HIP runtime that have a conflict with SYCL RT internals in terms of order. It seems to be a HIP specific issue. I am pretty hesitant to disable proper shutdown cleanup on Linux because of that.

bool allowWait =
MemObj->hasUserDataPtr() || GlobalHandler::instance().isOkToDefer();
if (!allowWait) {
StrictLock = false;
}
#else
bool allowWait = true;
#endif

if (allowWait) {
// This only needs a shared mutex as it only involves enqueueing and
Expand Down
4 changes: 0 additions & 4 deletions sycl/test-e2e/Regression/static-buffer-dtor.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,6 @@
// RUN: %{build} -o %t.out
// RUN: %{run} %t.out

// Failing on HIP AMD
// UNSUPPORTED: hip
// UNSUPPORTED-TRACKER: https://github.com/intel/llvm/issues/22300

#include <sycl/detail/core.hpp>

int main() {
Expand Down
20 changes: 17 additions & 3 deletions unified-runtime/source/adapters/hip/event.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -53,11 +53,25 @@ ur_result_t ur_event_handle_t_::release() {
return UR_RESULT_SUCCESS;

assert(Queue != nullptr);
UR_CHECK_ERROR(hipEventDestroy(EvEnd));

// During runtime/process shutdown the HIP context may already have been
// destroyed (e.g. static SYCL buffer destructors that run after the SYCL
// runtime released its contexts). The backing events are torn down together
// with the context, so treat these shutdown-specific errors as a successful
// release rather than surfacing an exception (which would otherwise abort in
// the event_impl destructor).
auto destroyEvent = [](hipEvent_t Event) {
hipError_t Res = hipEventDestroy(Event);
if (Res == hipErrorContextIsDestroyed || Res == hipErrorDeinitialized)
return;
UR_CHECK_ERROR(Res);
};

destroyEvent(EvEnd);

if (HasProfiling) {
UR_CHECK_ERROR(hipEventDestroy(EvQueued));
UR_CHECK_ERROR(hipEventDestroy(EvStart));
destroyEvent(EvQueued);
destroyEvent(EvStart);
}

return UR_RESULT_SUCCESS;
Expand Down
Loading