SnappyFile::rawWrite Segfault

[Kain Osterholt]

Thanks, Jose!  I was able to figure it out.  The problem was that we had
glEnableClientState calls for VERTEX_ARRAY and TEXCOORD_ARRAY without
disabling them in one of our render paths.  The next render path did not
disable these states either so a smaller texcoord/vertex array pair was
bound than the size that was passed to glDrawElements.  Once I disabled the
arrays appropriately the crashes went away.

The assumption that the size of the currently bound texcoord/vertex arrays
are the same as the size passed into DrawElements, is not always true.
 This is because you can call glDrawElements without using the fixed
function arrays and just use vertex attributes in a fully programmable
fashion.  Of course that means that we were sending unused texcoord and
vertex data to the GL pipeline which is wasteful so I like that this caught
the issue in the first place.

On Wed, Oct 17, 2012 at 10:31 AM, José Fonseca <jose.r.fonseca at gmail.com>wrote:

> 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?
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>


-- 

-Kain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20121017/62300d5c/attachment.html>