Is this a regression?  If so, could you bisect?

mesa: db726b048e8858af226dbd0f0fda72d0be01394e (master)

Saw this crash again while running VMware Workstation.

(gdb) bt
[...]
#17 0x0124245d in validate_reg (insn=<value optimized out>, reg=...) at brw_eu_emit.c:193
#18 0x012427a6 in brw_set_src0 (p=<value optimized out>, insn=0x32dd728, reg=...) at brw_eu_emit.c:233
#19 0x012434ce in brw_alu2 (p=0x32dd498, opcode=<value optimized out>, dest=..., src0=..., src1=...) at brw_eu_emit.c:755
#20 0x01239ffa in compute_offset (c=0x32dd498) at brw_clip_unfilled.c:187
#21 brw_emit_unfilled_clip (c=0x32dd498) at brw_clip_unfilled.c:469
#22 0x012324bd in compile_clip_prog (brw=0xd5eb530, key=0x33048dc) at brw_clip.c:120
#23 0x01232665 in upload_clip_prog (brw=0xd5eb530) at brw_clip.c:274
#24 0x01256559 in brw_validate_state (brw=0xd5eb530) at brw_state_upload.c:480
#25 0x0123f332 in brw_try_draw_prims (ctx=0xd5eb530, arrays=0xc9a1474, prim=0x3304a0c, nr_prims=1, ib=0x3304a20, index_bounds_valid=0 '\000', min_index=0, max_index=624) at brw_draw.c:340
#26 brw_draw_prims (ctx=0xd5eb530, arrays=0xc9a1474, prim=0x3304a0c, nr_prims=1, ib=0x3304a20, index_bounds_valid=0 '\000', min_index=0, max_index=624) at brw_draw.c:431
#27 0x0134c664 in vbo_validated_drawrangeelements (ctx=0xd5eb530, mode=4, index_bounds_valid=0 '\000', start=4294967295, end=4294967295, count=3456, type=5123, indices=0x0, basevertex=0, 
    numInstances=1) at vbo/vbo_exec_array.c:846
#28 0x0134c8d5 in vbo_exec_DrawElements (mode=4, count=3456, type=5123, indices=0x0) at vbo/vbo_exec_array.c:1003
[...]
(gdb) frame 17
#17 0x0124245d in validate_reg (insn=<value optimized out>, reg=...) at brw_eu_emit.c:193
193	   assert(execsize >= width);
(gdb) info locals
hstride_for_reg = {0, 1, 2, 4}
vstride_for_reg = {0, 1, 2, 4, 8, 16, 32, 64, 128, 256}
width_for_reg = {1, 2, 4, 8, 16}
execsize_for_reg = {1, 2, 4, 8, 16}
width = 4
hstride = <value optimized out>
vstride = 4
execsize = 2
__PRETTY_FUNCTION__ = "validate_reg"

I encountered this bug with a very recent version of mesa (git-02b808b). It was triggered by the osgmanipulator example program from OpenSceneGraph-3.1.6+. Simply click around whilst holding the Control key until the program crashes.

#0  0x00007ffff5ef55b5 in raise () from /lib64/libc.so.6
#1  0x00007ffff5ef6a38 in abort () from /lib64/libc.so.6
#2  0x00007ffff5eee632 in ?? () from /lib64/libc.so.6
#3  0x00007ffff5eee6e2 in __assert_fail () from /lib64/libc.so.6
#4  0x00007ffff2c5c7cf in validate_reg (insn=0x7fffec207a80, reg=...) at brw_eu_emit.c:207
#5  0x00007ffff2c5c9f9 in brw_set_src0 (p=0x7ffff0b1dde0, insn=0x7fffec207a80, reg=...) at brw_eu_emit.c:261
#6  0x00007ffff2c5e30f in brw_alu2 (p=0x7ffff0b1dde0, opcode=65, dest=..., src0=..., src1=...) at brw_eu_emit.c:768
#7  0x00007ffff2c5f52a in brw_MUL (p=0x7ffff0b1dde0, dest=..., src0=..., src1=...) at brw_eu_emit.c:1010
#8  0x00007ffff2c4e7be in compute_offset (c=0x7ffff0b1dde0) at brw_clip_unfilled.c:200
#9  0x00007ffff2c4f741 in brw_emit_unfilled_clip (c=0x7ffff0b1dde0) at brw_clip_unfilled.c:496
#10 0x00007ffff2c4860e in compile_clip_prog (brw=0x6dc690, key=0x7ffff0b1e0c0) at brw_clip.c:95
#11 0x00007ffff2c48c19 in brw_upload_clip_prog (brw=0x6dc690) at brw_clip.c:250
#12 0x00007ffff2ca7a5f in brw_upload_state (brw=0x6dc690) at brw_state_upload.c:497
#13 0x00007ffff2c57330 in brw_try_draw_prims (ctx=0x6dc690, arrays=0x73f7f0, prim=0x7fffec007a00, nr_prims=1, ib=0x0, 
    min_index=0, max_index=3) at brw_draw.c:501
#14 0x00007ffff2c576a1 in brw_draw_prims (ctx=0x6dc690, prim=0x7fffec007a00, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', 
    min_index=0, max_index=3, tfb_vertcount=0x0) at brw_draw.c:589
#15 0x00007ffff26ee127 in vbo_save_playback_vertex_list (ctx=0x6dc690, data=0x7fffec01e410)
    at ../../../src/mesa/vbo/vbo_save_draw.c:315
#16 0x00007ffff258f87b in ext_opcode_execute (ctx=0x6dc690, node=0x7fffec01e408) at ../../../src/mesa/main/dlist.c:599
#17 0x00007ffff25a3ddb in execute_list (ctx=0x6dc690, list=5) at ../../../src/mesa/main/dlist.c:7327
#18 0x00007ffff25a9471 in _mesa_CallList (list=5) at ../../../src/mesa/main/dlist.c:8723
#19 0x00007ffff73031c4 in draw (renderInfo=..., this=<optimized out>)
    at /usr/src/debug/dev-games/openscenegraph-9999/openscenegraph-9999/include/osg/Drawable:893

(gdb) frame 4
#4  0x00007ffff2c5c7cf in validate_reg (insn=0x7fffec207a80, reg=...) at brw_eu_emit.c:207
207        assert(execsize >= width);

(gdb) info locals
hstride_for_reg = {0, 1, 2, 4}
vstride_for_reg = {0, 1, 2, 4, 8, 16, 32, 64, 128, 256}
width_for_reg = {1, 2, 4, 8, 16}
execsize_for_reg = {1, 2, 4, 8, 16}
width = 4
hstride = 1
vstride = 4
execsize = 2
__PRETTY_FUNCTION__ = "validate_reg"

(gdb) l
202               insn->header.execution_size < Elements(execsize_for_reg));
203        execsize = execsize_for_reg[insn->header.execution_size];
204
205        /* Restrictions from 3.3.10: Register Region Restrictions. */
206        /* 3. */
207        assert(execsize >= width);
208
209        /* 4. */
210        if (execsize == width && hstride != 0) {
211           assert(vstride == -1 || vstride == width * hstride);

I am also seeing this bug [1]. Given its age, I don't think bisection will lead very far (in fact, I tried to bisect it but stumbled across a lot of issues, like .c files not in the build tree where they should be, etc.).

Is there something else I could do? I can easily reproduce the issue.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743885

(In reply to comment #4)
> I am also seeing this bug [1]. Given its age, I don't think bisection will
> lead very far (in fact, I tried to bisect it but stumbled across a lot of
> issues, like .c files not in the build tree where they should be, etc.).
> 
> Is there something else I could do? I can easily reproduce the issue.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743885

Yes, if you could provide an apitrace that reproduces the issue it would help a lot.

I tried with apitrace[1], but all I get are empty tracefiles (I have verified that glxgears works). It seems that the crash of Octave prevents the trace file from being written.

[1] https://github.com/apitrace is the correct one, isn't it?

(In reply to comment #6)
> I tried with apitrace[1], but all I get are empty tracefiles (I have
> verified that glxgears works). It seems that the crash of Octave prevents
> the trace file from being written.
> 
> [1] https://github.com/apitrace is the correct one, isn't it?

Yes, that's right.

To capture the trace, try running a release build of Mesa (i.e., one without assertions) or perhaps an older version that does not have this bug.

Created attachment 105150 [details]
Mesa trace with disabled assertions

Okay, here is the trace.
Mesa: d682ebec0bb8716dfa7747c46d5bfad732ead06c

configure call:
./configure   --prefix=/usr \
              --enable-driglx-direct \
              --enable-gles1 \
              --enable-gles2 \
              --enable-glx-tls \
              --with-dri-driverdir=/usr/lib/dri \
              --with-egl-platforms='drm x11' \
              --enable-debug \
              --with-dri-drivers=i965 \
              --with-gallium-drivers="" \
              CPPFLAGS=-DNDEBUG CFLAGS="-g -O0" CXXFLAGS="-g -O0"

I used the compiled libraries as described at http://x.debian.net/howto/build-mesa.html.
Attached is the trace without assertions.

(In reply to comment #8)
> Created attachment 105150 [details]
> Mesa trace with disabled assertions

Sorry, this doesn't look like a valid trace. (I can't replay it after xz -d with glretrace).

Ah sorry. The previous upload (octave-cli.trace.txt.lzma) is a dumped trace. I will upload the original binary trace file as well.

Created attachment 105334 [details]
Original binary Mesa trace with disabled assertions

Oh hey, I happened to fix this a while back when looking at a different bug.

commit b7679639bcc8ac72cb08c48f9cda8eecd6a9c1e5
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Aug 5 23:57:17 2014 -0700

    i965/clip: Fix brw_clip_unfilled.c/compute_offset's assembly.
    
    Due to the destination register width of 1 or 2, these instructions get
    ExecSize 1 or 2.  But dir and offset (used as src0) are both registers
    of width 4, violating the execsize >= width assertion.
    
    I honestly don't think this could have ever worked.
    
    Fixes Piglit's polygon-offset and polygon-mode-offset tests on Gen4-5.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70441
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>

The fix will be in 10.3, and I've nominated it for stable releases as well, so it may end up in 10.2.x at some point.

I cannot confirm that the patch fixes the problem. I have updated my whole system and now I no longer see an assertion, but my whole X server is taken down - which means that I have no idea where the problem lies. This happens with our without supplying NDEBUG as parameter.
However, as written in comment #9, I was using master of as d682ebec0bb8716dfa7747c46d5bfad732ead06c, which should include Kenneth's patch from comment 13, shouldn't it?