[Mesa-dev] EXTERNAL: Re: Clover clEnqueue* function don't implement blocking?

[Dorrington, Albert]

> -----Original Message-----
> From: Francisco Jerez [mailto:currojerez at riseup.net]
> > In the case where I had the 23,328 events in the queue, at least two
> > dozen kernels has been compiled, and each kernel had been executed 6
> times, with different input parameters.
> > (I would have to back the changes out to get exact numbers)
> >
> > From all appearances, the queued_events queue was never being flushed
> until the clFinish() call.
> >
> 
> And how exactly does that lead to a crash?
> 

From the analysis I was doing over the weekend, when the clFinish() is called, there were 23,328 events listed in queued_events.
The flush routine appears to be recursive, and processed approximage 20,000 of the events, before seg-faulting.
When I looked at the backtrace and structures, it appeared that the reference that was being flushed, no longer held valid information for the type of data it was supposed to hold.
More than likely, this occurred since the resource was released back to the system after a clEnqueue call, and reused by another resource of a different type.

I think that, since the corresponding resource tracked via the queued_events list had not been flushed, when the clFinish() flushing tried calling what would have been a function pointer for the original object's destroy routine, it saw a different value, which was erroneously processed as a function pointer. That function pointer was out of scope, resulting in the seg-fault.

Rather than dig into the details to try and figure out what object (out of 23,328 potential objects) may have reused the same area of memory; I took a step back and said to myself 'why are there so many items in the queued_events list? Why aren't they being cleared off sooner?'

Which lead me to the OpenCL specification statements that indicate that the queue should be flushed during the clEnqueue* calls, if the blocking flag is set true.