tracing on demand

[José Fonseca]

On Wed, Mar 27, 2013 at 2:00 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> On Wed, Mar 27, 2013 at 12:14 PM, Eugene Velesevich
> <eugvelesevich at gmail.com> wrote:
>>  Incidentally, I think such organization have resulted in a qapitrace bug.
>> Example:
>>  We are tracing a multithreaded application. The first thread calls some GL
>> function and writes the Enter() section into the trace file. At the same
>> moment, the second thread makes swapbuffers call and writes into the trace
>> file. Then the first writes the Leave() section.
>>
>> Open the tracefile. Qapitrace passes the trace file and creates the list of
>> frames. The traceloader makes a frame boundary bookmark on the second part
>> of the first thread's call (the first part is present in the parser buffer).
>> But when we open this frame, the buffer will not keep the first part and
>> qapitrace will crash.
>
> I see..
>
> We should hack qapitrace to not crash here. If you have a trace that
> reproduces this handy it would be great.

This should be fixed now. See https://github.com/apitrace/apitrace/issues/117

Jose