SnappyFile::rawWrite Segfault

[Kain Osterholt]

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.  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?

On Mon, Oct 15, 2012 at 12:08 PM, José Fonseca <jose.r.fonseca at gmail.com>wrote:

> Hi,
>
> If this is happening, then that's because the user array in question,
> 0xbfa98ba0, is either invalid or smaller than 21960.
>
> This could be an application bug -- passing insufficient data to the
> GL application -- or an apitrace bug (over-estimating the size to be
> 21960)
>
> If you have access to the source code, it should be possible to infer
> where the problem lies.
>
> Jose
>
>
> On Mon, Oct 15, 2012 at 5:51 PM, Kain Osterholt
> <kain.osterholt at gmail.com> wrote:
> > Hi all,
> >
> > I have recently encountered an issue both in apitrace 3.0 and the tip of
> the
> > source as of last friday.  I get a segmentation fault in the trace
> writer in
> > SnappyFile::rawWrite.  From the backtrace it looks like this originates
> from
> > a glDrawElements call.  I am attaching the partial stack here.  I still
> > haven't figured out what the difference in this particular DrawElements
> call
> > is to cause the issue.  The same rendering pipeline is traced fine for
> > another game I am working on so it seems that there is some specific
> feature
> > or mesh that isn't playing nicely with the writer.  Can anyone provide
> any
> > insight in debugging such an issue?  I'm new to apitrace so any help in
> > understanding how to report such issues better in the future would be
> > welcome as well.
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x40fd86af in ?? () from /lib/i386-linux-gnu/libc.so.6
> > (gdb) bt
> > #0  0x40fd86af in ?? () from /lib/i386-linux-gnu/libc.so.6
> > #1  0x4018d7a2 in SnappyFile::rawWrite (this=0xacd3e08,
> buffer=0xbfa98ba0,
> > length=21960)
> >     at /usr/include/i386-linux-gnu/bits/string3.h:52
> > #2  0x40189408 in write (this=<optimized out>, length=21960,
> > buffer=0xbfa98ba0) at /apitrace/common/trace_file.hpp:119
> > #3  _write (dwBytesToWrite=21960, sBuffer=0xbfa98ba0, this=<optimized
> out>)
> > at /apitrace/common/trace_writer.cpp:82
> > #4  trace::Writer::writeBlob (this=0x401fdec0, data=0xbfa98ba0,
> size=21960)
> > at /apitrace/common/trace_writer.cpp:262
> > #5  0x40165e4e in _trace_user_arrays (count=2745) at
> > /apitrace/build/wrappers/glxtrace.cpp:82774
> > #6  0x4016cc8b in glDrawElements (mode=4, count=3600, type=5123,
> > indices=0x0)
> >     at /apitrace/build/wrappers/glxtrace.cpp:2288
> >
> > _______________________________________________
> > 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/20121016/ecb4b6e2/attachment.html>