Created attachment 8555 [details]
test case

You can change the Macro: "#define MAX_TEXTURES 8" to control how much texture units to be used.
If change the Macro value to 7, the case will pass.

Changed the subject and moved to 965 driver, since sounds like just a segfault in the DRI driver.

It would be better to paste the stack info provided by gdb (bt), which may tell the exact calling path :)

I gave a quick try of this attached code (named as multitex.c) and found that the code break at " _XSend(dpy, (char *)ctx->buf, size) " (line 1372, glx/x11/glxext.c) which is called by __glXFlushRenderBuffer(), here is the calling stack:


#0  __glXFlushRenderBuffer (ctx=0x8050ef0, pc=0xb7bff2d4 "") at glxext.c:1374
#1  0xb7ee567d in __indirect_glFlush () at single2.c:507
#2  0xb7ef81ea in glFlush () at ../../../src/mesa/glapi/glapitemp.h:1170
#3  0x08048d4d in test () at multitex.c:55
#4  0x08048f69 in display () at multitex.c:101
#5  0xb7e161ff in processWindowWorkList (window=0x804fcf8) at glut_event.c:1302
#6  0xb7e16cd2 in glutMainLoop () at glut_event.c:1349
#7  0x08048fe5 in main (argc=1, argv=0xbfc905b4) at multitex.c:113

Below is GDB info when DRI is enabled:

(gdb) p p->program->NumAluInstructions 
$4 = 15
(gdb) c
Continuing.

Breakpoint 2, emit_arith (p=0xbfab9e80, op=OPCODE_END, dest=
      {file = 10, idx = 255, negatebase = 0, abs = 0, negateabs = 0, swz = 0, pad = 0}, mask=15, saturate=0 '\0', src0=
      {file = 10, idx = 255, negatebase = 0, abs = 0, negateabs = 0, swz = 0, pad = 0}, src1=
      {file = 10, idx = 255, negatebase = 0, abs = 0, negateabs = 0, swz = 0, pad = 0}, src2=
      {file = 10, idx = 255, negatebase = 0, abs = 0, negateabs = 0, swz = 0, pad = 0}) at main/texenvprogram.c:509
509     {
(gdb) c
Continuing.

Breakpoint 3, emit_arith (p=0xbfab9e80, op=Variable "op" is not available.
) at main/texenvprogram.c:526
526        p->program->NumAluInstructions++;
(gdb) bt
#0  emit_arith (p=0xbfab9e80, op=Variable "op" is not available.
) at main/texenvprogram.c:526
#1  0xb7b7024e in _mesa_UpdateTexEnvProgram (ctx=0x8057a08)
    at main/texenvprogram.c:1076
#2  0xb7b668a5 in _mesa_update_state_locked (ctx=0x8057a08)
    at main/state.c:1141
#3  0xb7b66928 in _mesa_update_state (ctx=0x8057a08) at main/state.c:1178
#4  0xb7c3b8d9 in _mesa_Clear (mask=16384) at main/buffers.c:134
#5  0xb7ee91da in glClear (mask=16384)
    at ../../../src/mesa/glapi/glapitemp.h:1100
#6  0x08048d0b in test () at multitex.c:35
#7  0x08049099 in display () at multitex.c:101
#8  0xb7f924bf in processWindowWorkList (window=0x804fce8) at glut_event.c:1302
#9  0xb7f92f92 in glutMainLoop () at glut_event.c:1349
#10 0x08049115 in main (argc=1, argv=0xbfaba364) at multitex.c:113
(gdb) p p->program->NumAluInstructions 
Cannot access memory at address 0x880
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xb7b6d70a in emit_arith (p=0xbfab9e80, op=Variable "op" is not available.
) at main/texenvprogram.c:526
526        p->program->NumAluInstructions++;
(gdb) 

Above info is simiarly with bug #9913. But in bug #9913, it applied texture combiner operations (GL_INTERPOLATE_ARB for GL_COMBINE_RGB_ARB;
GL_ADD_SIGNED_ARB for GL_COMBINE_ALPHA_ARB). If it do not applied texture combiner operation, it can pass.

Looks to me like the buffer holding the instructions is too small (#define MAX_INSTRUCTIONS 24), despite the comment 21 would be enough. At first sight, it looks like the maximum number of instructions could be as high as 6 per unit (1 tex load, 2 * 2 + 1 arithmetic (some modes require 2 arithmetic instructions, can have different mode for RGB and A, plus 1 for shift), plus the final 3 for separate specular and the END opcode respectively. That's 51.

The comment about 21 instructions was mine.  I could be wrong though.  Roland's analysis sounds correct.  Does this fix things?

#define MAX_INSTRUCTIONS ((MAX_TEXTURE_UNITS * 6) + 10)

Adding 10 just to be safe.

With i915 driver, the bug also exists.

(In reply to comment #8)
> With i915 driver, the bug also exists.

The bug should be driver-independant (as long as the driver uses mesa's code to convert texture state to fragment programs).
So, does Brian's fix help?

*** Bug 9913 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> The comment about 21 instructions was mine.  I could be wrong though.  Roland's
> analysis sounds correct.  Does this fix things?
> 
> #define MAX_INSTRUCTIONS ((MAX_TEXTURE_UNITS * 6) + 10)

It works well. I check it into git

mesa commit dcfdb63b9fde8134562cb3a4e779a36e0abb4ae5

Mass version move, cvs -> git