tracing on demand

[José Fonseca]

On Wed, Mar 27, 2013 at 12:14 PM, Eugene Velesevich
<eugvelesevich at gmail.com> wrote:
>
>
> 2013/3/27 José Fonseca <jose.r.fonseca at gmail.com>
>>
>> On Tue, Mar 26, 2013 at 4:48 PM, Peter Lohrmann
>> <peterl at valvesoftware.com> wrote:
>>
>> > Another question: is there a particular reason the _gl* api call is made
>> > between Begin\EndEnter() and Begin\EndLeave() calls to the localWriter?
>>
>> A lock is held between inside the Begin/EndEnter()  pair, and the
>> Begin/EndLeave().  It's better to call the real GL call without the
>> lock held, or it could potentially deadlock.
>
>
> The Enter() section and the Leave() one uses a recursive mutex, therefore
> even if the "real" GLcall calls another one, deadlock will not occur. Am I
> missing something here?
>
>> > Do the Enter and Leave sections get utilized in the retrace to help with
>> > profiling? or is it primarily for organization of the trace file?
>>
>> It is for organization of the trace file, particular in respect to
>> multithreaded calls (where you can have two calls in two threads that
>> overlap in time) , or reentrant calls (e.g, wglSetPixelFormat
>> typically ends causing other wgl calls before returning, which could
>> be quite confusing).
>>
>> So although the dumps attempt to show calls as a linear and ordered
>> sequence, reality could be much more complicated, but no matter how
>> complex reality is, trace binary representation can handle all weird
>> cases.
>
>
>  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.

The proper fix however requires a deeper change in qapitrace -- for
multithreaded apps, frame start/end should be tracked per thread, and
not per process.

Jose