I have discovered what I consider to be a bug in the reference tracking for cl_command_queue instances that leads to a segmentation fault under a reasonable usage scenario.
The cl_command_queue reference count is not incremented when a cl_event instance is created. It should be.
clReleaseCommandQueue can be called while there are still cl_event instances that have not been released. Now, in this case, it is still possible to get a reference to the command queue associated with cl_event by calling clGetEventInfo ( cl_event event, CL_EVENT_COMMAND_QUEUE, , &queue ... ).
I experience a segmentation fault if I use that queue reference to get information about the command queue, for example: clGetCommandQueueInfo( command_queue, CL_QUEUE_DEVICE, ...)
My output shows the queue reference count is unaffected by the event lifecycle. The cl_context reference count also remains fixed. This may or may not be ok. I did not explore it.
$ g++ -o bugDemo command_queue_ref_cnt_demo.cpp bugDemoSupport.cpp -I/opt/intel/opencl/include $ ./bugDemo -p 1 Selected CL_PLATFORM_NAME: Intel(R) OpenCL CL_DEVICE_NAME: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz CL_DRIVER_VERSION: 18.104.22.168248 reference count after instantiation: context 1, queue 1 reference count after creating an event: context 1, queue 1 reference count after releasing the event: context 1, queue 1
The Apple implementation does not suffer this problem. The queue reference count tracks the number of event instances associated with that queue:
$ ./bugDemo Selected CL_PLATFORM_NAME: Apple CL_DEVICE_NAME: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz CL_DRIVER_VERSION: 1.1 reference count after instantiation: context 2, queue 1 reference count after creating an event: context 4, queue 2 reference count after releasing the event: context 3, queue 1