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.<div>
<br></div><div>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.<br>
<br><div class="gmail_quote">On Wed, Oct 17, 2012 at 10:31 AM, José Fonseca <span dir="ltr"><<a href="mailto:jose.r.fonseca@gmail.com" target="_blank">jose.r.fonseca@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Oct 16, 2012 at 5:10 PM, Kain Osterholt<br>
<<a href="mailto:kain.osterholt@gmail.com">kain.osterholt@gmail.com</a>> wrote:<br>
> Thanks!<br>
><br>
> I was able to debug this a bit more.  It seems like the _trace_user_arrays<br>
> call in glDrawElements assumes that the number of verts is the maximum<br>
> index.<br>
<br>
</div>_trace_user_arrays gets the number of vertices from<br>
_glDrawElements_count() which walks over all indices and takes the<br>
maximum.<br>
<br>
One possible explanation is that the application is using primitive<br>
restart, and uses a big index number (e.g., 0xffffffff) to mark<br>
restart.<br>
<br>
Please try the attached primitive restart patch.<br>
<br>
It is also possible that the app is using NV_primitive_restart. The<br>
patch needs to be slightly modified to handle that.<br>
<br>
Jose<br>
<div class="HOEnZb"><div class="h5"><br>
> This is then assumed to factor into the size of the buffer that<br>
> holds the texture coordinates.  However, our texture coords are in VBOs and<br>
> then vertex attributes are used to consume that data in the shader pipeline.<br>
> I think our client state still had TEX_COORD_ARRAY enabled from a legacy<br>
> pipeline render call.  So now you have a mismatch in the number of texture<br>
> coords actually present and the assumption based on glDrawElements.  GL<br>
> without trace doesn't have a problem with this so should there be a way to<br>
> determine the actual texture coordinates bound?<br>
</div></div><br>_______________________________________________<br>
apitrace mailing list<br>
<a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Kain <br>
</div>