Bug 28110

I first got this from a background process:
Mesa 7.7.1 implementation error: bad datatype in interpolate_int_colors
Please report at bugzilla.freedesktop.org
Mesa 7.7.1 implementation error: ...
... 
then the program crashes.

So I ran it through valgrind and watched it to get more detail, and long before the "implementation error," valgrind is spitting out issues with glMultiDrawElements.

The first is:
==26120== Conditional jump or move depends on uninitialised value(s)
==26120==    at 0xF1BC2B5: triangle_offset_twoside_rgba (ss_tritmp.h:88)
==26120==    by 0xF14B199: _tnl_render_poly_elts (t_vb_rendertmp.h:352)
==26120==    by 0xF14B87A: run_render (t_vb_render.c:320)
==26120==    by 0xF13EE19: _tnl_run_pipeline (t_pipeline.c:157)
==26120==    by 0xF1404CF: _tnl_draw_prims (t_draw.c:467)
==26120==    by 0xF140835: _tnl_vbo_draw_prims (t_draw.c:376)
==26120==    by 0xF130DE2: vbo_validated_multidrawelements (vbo_exec_array.c:935)
==26120==    by 0xF1312B3: vbo_exec_MultiDrawElements (vbo_exec_array.c:984)
and there are many more afterwards coming from MultiDrawElements.

A bunch of triangles on the screen look very distorted.

I'm not seeing this problem using nVidia's libGL.

Created attachment 35658 [details]
testcase

I've attached a simple test case.  It doesn't draw correctly with Mesa, but does draw correctly with nVidia's libGL.

Created attachment 36478 [details] [review]
patch to fix min/max index computation

Can you try the attached patch against Mesa git/master or 7.8.x?

Created attachment 36479 [details]
backtrace.txt

It does help and my smaller data sets render correctly.
But it appears when I get to larger arrays, I get an infinite loop or something.
I'm attaching a backtrace when I interrupted it in a debugger.

(In reply to comment #4)
> Created an attachment (id=36479) [details]
> backtrace.txt
> 
> It does help and my smaller data sets render correctly.
> But it appears when I get to larger arrays, I get an infinite loop or
> something.
> I'm attaching a backtrace when I interrupted it in a debugger.

Can you set a breakpoint on _tnl_vbo_draw_prims() and see if it's getting called a lot or if you're stuck down inside it?

> (In reply to comment #4)
> Can you set a breakpoint on _tnl_vbo_draw_prims() and see if it's getting
> called a lot or if you're stuck down inside it?

_tnl_vbo_draw_prims() is called repeatedly.

In vbo_split_copy.c line 591 I see
for (i = 0; i < nr_prims;)
{ ....

and i starts at 0, then goes to 16 and stays at 16 for many iterations afterwards.
It also appears one iteration takes too long, considering the size of the data.

So basically, it won't come out of vbo_split_copy().(In reply to comment #5)

The test case doesn't work with swrast/r300c, but works with Gallium.

Triaging somewhat.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/295.