Buffers destroyed too early in some ViennaCL cases

[Pekka Jääskeläinen]

OpenCL 1.2 Page 118:

After the memobj reference count becomes zero and commands queued for execution on a command-queue(s) that use memobj have finished, the memory object is deleted. If memobj is a buffer object, memobj cannot be deleted until all sub-buffer objects associated
with memobj are deleted.

Some ViennaCL cases crash if the freeing of buffers is enabled in clReleaseMemObject() as ViennaCL seems to use the same mem objects in multiple kernels and they get freed too early. Maybe the C++ bindings do not retain correctly in copy constructors? Or it relies on the "command-queues that use memobj have finished" part so we should check for that before destroying the objects which is not trivial.

[Pekka Jääskeläinen (pekka-jaaskelainen)]

It could be enough if all the queued commands that use buffers (enqueue, map, read/write, copy, ..) retain the buffers they use and after finishing execution in clFinish release it. In ViennaCL case I think the crash was due to a buffer copy operation which didn't retain the src&dst buffers.

[Karl Rupp (karlrupp)]

I'm the ViennaCL head and just got notified about this bug report. Could you please provide some informations about how to reproduce the issue in order to fix it? Cheers!

[Pekka Jääskeläinen (pekka-jaaskelainen)]

Hi there.

ViennaCL has been a good test case -- it has produced a lot of bugs in pocl. Also in this case I think the issue is/was in pocl implementation: pocl was too eager to free the buffers (in clReleaseBuffer) even though there was a copy operation (referring to that buffer) still in a command queue.

I will probably fix this by calling clRetainBuffer in the clEnqueueCopyBuffer for the src and dst. Similarly for the kernel args with clEnqueueNDRangeKernel. clReleaseBuffer can be then called in clFinish after those commands have been executed. For now the mem buffers are never freed so it leaks a lot of memory.

But thanks anyways. FYI, currently there are still two different known crashes in pocl produced by ViennaCL but it looks quite good finally.

[Karl Rupp (karlrupp)]

Hi Pekka,

thanks for the quick response. :-)
We experienced some issues on MacOS some time ago, which boiled down to the OpenCL implementation on MacOS having issues with memory handles wrapped in static objects. It took us quite a while to figure that out (assuming it was a bug in ViennaCL, but it wasn't), that's why I'm pretty sensitive on that topic ;-)

I'm glad we can provide a good stress test for pocl. Keep up the work on pocl, I'm really looking forward to have a stable open source OpenCL implementation! :-)

[Pekka Jääskeläinen (pekka-jaaskelainen)]

 Mem objects are now retained in clEnqueue(NDRangeKernel,Read,Write,Copy) and
 released in clFinish(). The ViennaCL tests still work so I assume the leak/crash is
 now fixed.