Comment # 8 on bug 80673 from Hadrien

It seems that what is happening is that the "end" argument is referencing a
vertex that does not exist when glDrawRangeElementsBaseVertex is called. The
documentation says that "start" and "end" are inclusive indices so I guess a
missing "-1" in the game code is the cause of the problem.

In the last callstack, the game informs the driver that vertices 0 to 64
(inclusive) should be used for drawing:
vbo_exec_DrawRangeElementsBaseVertex(mode=4, start=0, end=64, count=168,
type=5123, indices=0x7f22c87bfeb0, basevertex=0)

And later the driver will upload data with those arguments:
u_vbuf_upload_buffers(mgr=0x7f22efa9e760, start_vertex=0, num_vertices=65,
start_instance=0, num_instances=1) 

So an attempt to upload 65 vertices is done for a range of [0..64], which is
correct as per the spec, but in my case the buffer only holds 64 elements.

I do not know how the driver can protect itself from such a case. I've been
looking at the glVertexPointer API but the client does not inform the driver of
the total size of the pointed buffer, so I don't know how to verify this kind
of out of bounds errors.

The only idea I have would be to scan all indices to get min and max values and
issue a warning if they do not fit exactly in the "start" and "end" indices.
However this would probably be ineffective as the purpose of "Range" functions
seems to be precisely to inform the driver of the range so it does not need to
compute it. Moreover, though it is ineffective to include useless vertices in
the range, the spec does not seem to forbid it.

Sadly, it seems there is nothing to do on the Mesa side. At least I will inform
the game developers about my analysis and then close this bug.