i965: Assert that the offset in the VBO is below the VBO size.

This avoids sending a bad buffer address to the GPU due to programmer error,
and is permitted by the ARB_vbo spec.  Note that we still have the opportunity
to dereference past the end of the GPU, because we aren't clipping to a
correct _MaxElement, but that appears to be harder than it should be.  This
gets us the 90% solution.

Bug #19911.
(cherry picked from commit d7430d942f6c7950a92367aeb13b80cf76ccad78)

diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index e7a87b6e09fbe4478ea52074af49ce17d5ce01b6..05079c043af5bbe086f86576cb60c1768179827b 100644 (file)
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -396,6 +396,20 @@ static void brw_prepare_vertices(struct brw_context *brw)
         dri_bo_reference(input->bo);
         input->offset = (unsigned long)input->glarray->Ptr;
         input->stride = input->glarray->StrideB;
+
+        /* This is a common place to reach if the user mistakenly supplies
+         * a pointer in place of a VBO offset.  If we just let it go through,
+         * we may end up dereferencing a pointer beyond the bounds of the
+         * GTT.  We would hope that the VBO's max_index would save us, but
+         * Mesa appears to hand us min/max values not clipped to the
+         * array object's _MaxElement, and _MaxElement frequently appears
+         * to be wrong anyway.
+         *
+         * The VBO spec allows application termination in this case, and it's
+         * probably a service to the poor programmer to do so rather than
+         * trying to just not render.
+         */
+        assert(input->offset < input->bo->size);
       } else {
         if (input->bo != NULL) {
            /* Already-uploaded vertex data is present from a previous