SnappyFile::rawWrite Segfault

[José Fonseca]

Good.

Yeah, apitrace might end up touching more vertex data than strictly
necessary, but it is dificult to prevent that.

Jose

On Wed, Oct 17, 2012 at 6:35 PM, Kain Osterholt
<kain.osterholt at gmail.com> wrote:
> 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