[Mesa-dev] [Bug 107295] Access violation on glDrawArrays with count >= 2048

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107295

--- Comment #4 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Paul from comment #2)
> I managed to build a debug version of Mesa3D 10.4.7 (version 18 is a
> pre-built binary without debugging information), and this is what I got for
> a callstack:
Thanks, but a callstack with a more recent version would have been more useful.

> The test program is, therefore, setting PT_PIPELINE while the actual program
> is not (what exactly causes clipped to be true or false in terms of the
> OpenGL context?).
Simple, if at least some of the vertices are outside the viewport clipped will
be set (if there's no gs, this will be determined directly in the generated
shader, otherwise draw_pt_post_vs_run() will determine it).
(PT_PIPELINE will also be already set if you hit the draw pipeline fallbacks,
such as drawing tris in wireframe or point mode, but it appears this isn't the
case here.)

> Forcing the code to call emit indraw_pt_post_vs_runstead of pipeline by using
> the debugger does reproduce the crash. Forcing the actual program to call
> pipeline instead of emit does not crash and does show the proper output.

> translate->key.output_stride = 32
> translate->key.nr_elements = 2
> vert_info->stride = 68
> vert_info->count = 101088
> 
> I assume the values are associated with the output of the geometry shader.
> There I specify a max_vertices of 32, and it produces 2 outputs: position
> and color. The 32 would also refer to the number of bytes for the output:
> position and color are both vec4. The 68 doesn't make sense, though. I do
> emit 32 vertices in batches of 4 vertices for a triangle strip primitive.
The 68 indeed is the stride of the output vertices of the gs here.
So 32 bytes plus the vertex header, though (should be 20 bytes, 4 floats for
clip pos, plus another 4 bytes for flag bits - I think it's 68 here and not 52
because you're using a prehistoric mesa version). 

I can reproduce this here. I think it might be a bug in the translate code but
not sure (valgrind shows it's writing past the allocated buffer size for the
output (driver) vertices). Or the parameters to it aren't quite right (it does
not appear to be a bug in the generated translate code directly, since if
that's commented out (see translate_create()) it'll crash in the memcpy used in
the generic path instead).

I'll try to look into this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180720/c0f8f3b1/attachment-0001.html>