llvm

bddb1288 - [UR][OpenCL] Break reference cycle between in-order queue and last event (#23076)

[UR][OpenCL] Break reference cycle between in-order queue and last event (#23076) ## Problem `ur_queue_handle_t_::storeLastEvent()` retained the `ur_event_handle_t_` it stores (`queue.hpp:71`), and `ur_event_handle_t_`'s constructor retains its `Queue` (`event.hpp:31`). For an **in-order** queue that is an unbreakable cycle: - queue -> `LastEvent` (strong, via `urEventRetain`) - event -> `Queue` (strong, via `urQueueRetain`) The queue's reference count never reaches zero, so `~ur_queue_handle_t_` never runs and its `urContextRelease` / `urDeviceRelease` never fire. **The queue, its context, its device and the event are all leaked for the lifetime of the process.** ## Proposed Fix Store the `cl_event` instead of the UR event, retained with `clRetainEvent` and released in the destructor. The queue only ever needed that event to answer `UR_QUEUE_INFO_EMPTY`, and a `cl_event` holds no reference back to the UR queue, so the cycle cannot form. The `UR_QUEUE_INFO_EMPTY` query now calls `clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS)` directly, which is the identical call the neighbouring branch for a queue with no stored event already made. ## How it was found An ASan+UBSan build of the runtime running `sycl/test-e2e/Basic` on `opencl:cpu`. LeakSanitizer reported it as **four indirect leaks with no direct leak at all**, which is the signature of a reference cycle (no chunk is unreferenced, so nothing qualifies as the root): ``` Indirect leak of 72 byte(s) in 1 object(s) allocated from: #2 ur::opencl::urQueueCreate(...) queue.cpp:165 Indirect leak of 56 byte(s) in 1 object(s) allocated from: #2 ur::opencl::urContextCreate(...) context.cpp:84 Indirect leak of 40 byte(s) in 1 object(s) allocated from: #2 ur::opencl::createUREvent(...) event.hpp:74 Indirect leak of 8 byte(s) in 1 object(s) SUMMARY: AddressSanitizer: 176 byte(s) leaked in 4 allocation(s). ``` The proposed fix resolves all the leaks. --- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>