Tom Stellard <thomas.stell...@amd.com> writes: > On Thu, Jun 28, 2012 at 01:09:20AM +0200, Francisco Jerez wrote: >> Tom Stellard <tstel...@gmail.com> writes: >> >> > We need to increment the reference count for objects, like cl_event, >> > that the user is responsible for destroying when they are returned from >> > the API. Otherwise, the object will be destroyed when clover is done with >> > it, even though the user will still have a reference to it. For example: >> > >> > 1. clEnqueueNDRangeKernel(queue, ... , &event) >> > - create an event object >> > - refcount = 1 >> > >> > 2. clFlush(queue) >> > - event object is removed from the queue and its reference count is >> > decremented. >> > - refcount = 0, event is deleted >> > >> > 3. clGetEventInfo(event, ...) >> > - segfault >> >> I don't think this could cause the problem you've seen... After step 1 >> the event object ends up queued in queue->queued_events, a ref_ptr<> >> list that holds additional references to each object it contains, so, >> after step 1 refcount is supposed to be 2 already... You're probably >> hitting something more subtle, try the attached patch. >> > > I missed that part about ref_ptr. I'll have to look at that again. > However that sequence is causing a segfault in clGetEventInfo in all > of the AMD OpenCL SDK examples (or at least all of them that make it > that far), and it is because the event is being deleted too early. > Yes, probably because the user-defined copy constructor of ref_ptr<hard_event> is not being used by the event queue because it's defined as a template, try the patch I attached.
>[...]
pgpm8jKAGMAyR.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
