[SYCL] Don't skip memory-record removal when buffer write-back throws

[uditagarwal97]

Problem

SYCLMemObjT::updateHostMemory() performs the write-back and then detaches the memory object from the scheduler:

void SYCLMemObjT::updateHostMemory() {
  if ((MUploadDataFunctor != nullptr) && MNeedWriteBack &&
      GlobalHandler::instance().isOkToDefer())
    MUploadDataFunctor();          // <-- can throw

  if (MRecord) {
    bool Result = Scheduler::getInstance().removeMemoryObject(...);
    ...
  }
  releaseHostMem(MShadowCopy);
  ...
}

MUploadDataFunctor() ends up in Scheduler::addCopyBack() followed by Event->wait(), and a failing copy-back throws from GraphProcessor::waitForEvent(). The exception then propagates out of updateHostMemory(), so removeMemoryObject(), releaseHostMem() and the interop urMemRelease() below it are all skipped. Both callers (~buffer_impl and ~image_impl) wrap the call in try { ... } catch (...) {}, so the failure is silently discarded and the object is destroyed with its scheduler record still attached.

The leaked set is the whole MemObjRecord: its alloca/release/copy-back/exec commands, the LeavesCollection, and — because Command::MQueue is a shared_ptr<queue_impl> — the queue and its context with the kernel/program caches. LeakSanitizer reported 41 allocations / ~10.7 KB for a single occurrence (SchedulerTest.FailedCopyBackException), all of them indirect leaks with no direct leak, which is the signature of an orphaned graph rather than a forgotten delete.

Fix

Contain the failure so the teardown below always runs:

if ((MUploadDataFunctor != nullptr) && MNeedWriteBack &&
    GlobalHandler::instance().isOkToDefer()) {
  // A failing write-back is reported as an asynchronous exception by
  // Scheduler::addCopyBack and must not skip the removal of the memory
  // record below, otherwise the record and the commands it owns are leaked.
  try {
    MUploadDataFunctor();
  } catch (...) {
  }
}

Observable behavior is unchanged: both existing callers already discarded this exception, and the failure is still reported to the user through the asynchronous exception Scheduler::addCopyBack() records.

---

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

[Copilot]

🟢 Approval recommended

The focused exception-handling change correctly preserves teardown while retaining asynchronous error reporting.

Pull request overview

Ensures failed SYCL buffer/image write-back does not prevent scheduler and memory cleanup.

Changes:

• Catches copy-back exceptions before teardown.
• Preserves memory-record, host-memory, and interop-resource cleanup.

File summaries

File	Description
sycl/source/detail/sycl_mem_obj_t.cpp	Prevents write-back failures from skipping memory-object cleanup.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.