José Fonseca

Sorry for the long delay replaying. Could you provide the trace per chance? Even if the issue happened during tracing and not replaying, and therefore the trace is hopelessly broken,...

No, there's not really an easy way to do this. But I really recommend tracing via CLI though. I'm not sure it's worth maintaining/improving GUI tracing. I feel tempted to...

I agree this is a sensible thing to do. In fact, it probably makes sense to do it by default. But this needs to be done in a way it...

> So somehow during the course of the trace, the pointers got mixed up so that both 0x4 and 0x7 refer to the same object. The problem is that there...

During trace, they can indeed happen simultaneously. But when replaying, glretrace enforces a order. See issue #401. So you're right: it's possible that a race condition that happen during tracing,...

> Optionally, I can send you the trace—it's large (3.8 GB) but you only need the first 100 MB or so of it to see these specific issues. I don't...

> Why is …729 so out of order? Hmm... ...729 is out of order because, even though `glDeleteSync` call started on event ...729, it actually only finished between ...887 and...

What I was thinking was of enforcing a strict ordering for calls to function pairs, by holding a mutex. Not a single global mutex, but one mutex per namespace: -...

I read https://www.opengl.org/registry/specs/ARB/sync.txt and indeed FenceSync does not do an implicit Flush: ``` If the sync object being blocked upon will not be signaled in finite time (for example, by...

Note that glretrace keeps swizzling sync names behind your back. The messages you see show the sync that was recorded, not the sync that was used when replayed. To see...