SnappyFile::rawWrite Segfault

José Fonseca jose.r.fonseca at gmail.com
Wed Oct 17 08:31:13 PDT 2012


On Tue, Oct 16, 2012 at 5:10 PM, Kain Osterholt
<kain.osterholt at gmail.com> wrote:
> Thanks!
>
> I was able to debug this a bit more.  It seems like the _trace_user_arrays
> call in glDrawElements assumes that the number of verts is the maximum
> index.

_trace_user_arrays gets the number of vertices from
_glDrawElements_count() which walks over all indices and takes the
maximum.

One possible explanation is that the application is using primitive
restart, and uses a big index number (e.g., 0xffffffff) to mark
restart.

Please try the attached primitive restart patch.

It is also possible that the app is using NV_primitive_restart. The
patch needs to be slightly modified to handle that.

Jose

> This is then assumed to factor into the size of the buffer that
> holds the texture coordinates.  However, our texture coords are in VBOs and
> then vertex attributes are used to consume that data in the shader pipeline.
> I think our client state still had TEX_COORD_ARRAY enabled from a legacy
> pipeline render call.  So now you have a mismatch in the number of texture
> coords actually present and the assumption based on glDrawElements.  GL
> without trace doesn't have a problem with this so should there be a way to
> determine the actual texture coordinates bound?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: primitive-restart.diff
Type: application/octet-stream
Size: 1777 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20121017/54e93594/attachment.obj>


More information about the apitrace mailing list