[Mesa-dev] [PATCH] clover: Increment an object's reference count in ret_object()

Tom Stellard thomas.stellard at amd.com
Thu Jun 28 07:31:42 PDT 2012


On Thu, Jun 28, 2012 at 03:47:23PM +0200, Francisco Jerez wrote:
> Tom Stellard <thomas.stellard at amd.com> writes:
> 
> > On Thu, Jun 28, 2012 at 01:09:20AM +0200, Francisco Jerez wrote:
> >> Tom Stellard <tstellar at 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.
> 
> >[...]


Your patch works.  Thanks.

-Tom



More information about the mesa-dev mailing list