Bug 9103

A fix for this was comitted today.

Could you please retest with CVS HEAD.

FWIW, I've just run into this assertion with r200 (and doom3).

Corresponding backtrace for that r200 doom3 crash (with tcl_mode 0, it segfaults
with 1 too):
#0  0x40017410 in ?? ()
#1  0xbfc8eed0 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00007bd9 in ?? ()
#4  0x4024a7a1 in raise () from /lib/tls/libc.so.6
#5  0x4024bf79 in abort () from /lib/tls/libc.so.6
#6  0x40243fe3 in __assert_fail () from /lib/tls/libc.so.6
#7  0x4191ab13 in _ae_invalidate_state (ctx=Variable "ctx" is not available.
) at main/api_arrayelt.c:1301
#8  0x4198898d in _tnl_InvalidateState (ctx=Variable "ctx" is not available.
) at tnl/t_context.c:158
#9  0x418efcaf in r200InvalidateState (ctx=0xa9bfd90, new_state=1024)
    at r200_state.c:2633
#10 0x41960041 in _mesa_update_state_locked (ctx=Variable "ctx" is not available.
) at main/state.c:1107
#11 0x419600e8 in _mesa_update_state (ctx=0xa9bfd90) at main/state.c:1118
#12 0x419b4300 in _tnl_flush_vtx (ctx=0xa9bfd90) at tnl/t_vtx_exec.c:277
#13 0x419ac46a in _tnl_wrap_buffers (ctx=Variable "ctx" is not available.
) at tnl/t_vtx_api.c:84
#14 0x419ac527 in _tnl_wrap_filled_vertex (ctx=0x0) at tnl/t_vtx_api.c:121
#15 0x419b1a13 in attrib_0_3 (v=Variable "v" is not available.
) at tnl/t_vtx_generic.c:100
#16 0x419af471 in _tnl_Vertex3fv (v=0x10d4461c) at tnl/t_vtx_generic.c:240
#17 0x4191b19d in _ae_loopback_array_elt (elt=629) at main/api_arrayelt.c:1286
#18 0x41a4a237 in fallback_drawelements (ctx=Variable "ctx" is not available.
) at tnl/t_array_api.c:75
#19 0x08156450 in ?? ()

Roland, does doom run if you simply remove/disable the assertion?

(In reply to comment #4)
> Roland, does doom run if you simply remove/disable the assertion?
Unfortunately not. It will just trigger another assertion (_ae_unmap_vbos, line
1235), removing this one will cause a segfault (in mesa_buffer_map, line 364).

If noone beats me to it, I'll look into it (tomorrow).

Roland,

This looks like mesa is convincing itself there has been a statechange in the
middle of a DrawElements call.  That's fairly disruptive...  

I'd say it's got to do with the fact that there is code setting ctx->_NewState
|= _NEW_LIGHT in _tnl_copy_to_current, which is slight overkill.  In any case it
shouldn't be hard to work around.

OK, I've changed the tnl code to only raise _NEW_LIGHT when materials are
present, which is never the case inside a drawelements call.  Please retest.

(In reply to comment #7)
> OK, I've changed the tnl code to only raise _NEW_LIGHT when materials are
> present, which is never the case inside a drawelements call.  Please retest.
Keith, this indeed fixes the assertions, but not the segfault in
mesa_buffer_map. Looks like that's another problem.
#0  0x418f95c7 in _mesa_buffer_map (ctx=0xa9bfdc0, target=34962, access=35048, 
    bufObj=0x21) at main/bufferobj.c:364
#1  0x418f6494 in _ae_map_vbos (ctx=0xa9bfdc0) at main/api_arrayelt.c:1218
#2  0x418f6605 in _ae_loopback_array_elt (elt=32) at main/api_arrayelt.c:1271
#3  0x41a24809 in fallback_drawelements (ctx=Variable "ctx" is not available.
) at tnl/t_array_api.c:75
#4  0x41a24e2c in _tnl_DrawElements (mode=4, count=12, type=5125, indices=0x3f)
    at tnl/t_array_api.c:393
#5  0x0815657f in ?? ()
Haven't looked into it but that bufObj pointer there sure looks bogus...

Roland,

It'd be great if you could take a closer look.  The problem with the
bogus-looking pointer is that it seems you're compiled with something higher
than -O0, which sometimes makes things look broken when they are fine.  See also
the indices pointer in _tnl_DrawElements further down your stacktrace.  In other
words, it's worth recompiling with -O0 before digging deeper.

But when you do, it would be good to know where this bufferobj pointer came from
- it looks suspciously like NULL plus a small offset.

(In reply to comment #9)
> Roland,
> 
> It'd be great if you could take a closer look.  The problem with the
> bogus-looking pointer is that it seems you're compiled with something higher
> than -O0, which sometimes makes things look broken when they are fine.  See also
> the indices pointer in _tnl_DrawElements further down your stacktrace.  In other
> words, it's worth recompiling with -O0 before digging deeper.
Ah well, I've used -O, which more often than not works quite ok. Some bugs
sneaked in due to that though... Here's a better trace, and some more
information. I'm a bit puzzled though, the boolean mapped_vbos is 112, nr_vbos
is 23 (no way doom3 is going to use that many attribs!), and those vbo objects
don't look good.
#0  0x41910dc8 in _mesa_buffer_map (ctx=0xa9bfd60, target=34962, access=35048, 
    bufObj=0x0) at main/bufferobj.c:364
#1  0x4190c7dc in _ae_map_vbos (ctx=0xa9bfd60) at main/api_arrayelt.c:1218
#2  0x4190c98e in _ae_loopback_array_elt (elt=32) at main/api_arrayelt.c:1271
#3  0x41ac11c7 in fallback_drawelements (ctx=0xa9bfd60, mode=4, count=12, 
    indices=0x4bfee340) at tnl/t_array_api.c:75
#4  0x41ac1a80 in _tnl_DrawElements (mode=4, count=12, type=5125, 
    indices=0x4bfee340) at tnl/t_array_api.c:393
#5  0x0815657f in ?? ()

p (AEcontext)ctx->aelt_context
$4 = {arrays = {{array = 0xb2a30b8, offset = 0}, {array = 0x419, 
      offset = 178088824}, {array = 0xa9a7778, offset = 178087792}, {
      array = 0x14, offset = 1701012289}, {array = 0x44207373, 
      offset = 1701408357}, {array = 0x64, offset = 0}, {array = 0xa, 
      offset = 178087824}, {array = 0x14, offset = 1920234275}, {
...
    NewState = 14393, vbo = {0xe, 
    0xa9d69f0, 0x14, 0x4e4e4f43, 0x49544345, 0x2e2e474e, 0x2e2e, 0x0, 0xa, 
    0xa9d6a10, 0x14, 0x72747323, 0x3030305f, 0x72003133, 0x3730305f, 0x3939, 
    0x10, 0xa9d6a30, 0x14, 0x4e4e4f43, 0x49544345, 0x45204e4f, 0x524f5252, 
    0x0, 0xa, 0xa9d6a50, 0x14, 0x72747323, 0x3030305f, 0x72003233, 0x3830305f, 
    0x3030}, nr_vbos = 23, mapped_vbos = 112 'p'}

p *ctx->Array->ArrayObj
$8 = {Name = 0, Vertex = {Size = 4, Type = 5126, Stride = 16, StrideB = 16, 
    Ptr = 0x0, Enabled = 1, Normalized = 0 '\0', BufferObj = 0xb0c0450, 
    _MaxElement = 78, Flags = 1}, Normal = {Size = 0, Type = 5126, Stride = 0, 
    StrideB = 0, Ptr = 0x0, Enabled = 0, Normalized = 0 '\0', 
    BufferObj = 0xa857788, _MaxElement = 0, Flags = 1}, Color = {Size = 4, 
    Type = 5126, Stride = 0, StrideB = 0, Ptr = 0x0, Enabled = 0, 
    Normalized = 0 '\0', BufferObj = 0xa857788, _MaxElement = 0, Flags = 1}, 
  SecondaryColor = {Size = 4, Type = 5126, Stride = 0, StrideB = 0, Ptr = 0x0, 
    Enabled = 0, Normalized = 0 '\0', BufferObj = 0xa857788, _MaxElement = 0, 
    Flags = 1}, FogCoord = {Size = 1, Type = 5126, Stride = 0, StrideB = 0, 
    Ptr = 0x0, Enabled = 0, Normalized = 0 '\0', BufferObj = 0xa857788, 
    _MaxElement = 0, Flags = 1}, Index = {Size = 0, Type = 5126, Stride = 0, 
    StrideB = 0, Ptr = 0x0, Enabled = 0, Normalized = 0 '\0', 
    BufferObj = 0xa857788, _MaxElement = 0, Flags = 1}, TexCoord = {{Size = 2, 
      Type = 5126, Stride = 60, StrideB = 60, 
      Ptr = 0xc <Address 0xc out of bounds>, Enabled = 0, Normalized = 0 '\0', 
      BufferObj = 0xb0c0f78, _MaxElement = 2731, Flags = 1}, {Size = 3, 
      Type = 5126, Stride = 12, StrideB = 12, Ptr = 0x0, Enabled = 0, 
      Normalized = 0 '\0', BufferObj = 0xb0c0418, _MaxElement = 2732, 
      Flags = 1}, {Size = 4, Type = 5126, Stride = 0, StrideB = 0, Ptr = 0x0, 
      Enabled = 0, Normalized = 0 '\0', BufferObj = 0xa857788, 
      _MaxElement = 0, Flags = 1}, {Size = 4, Type = 5126, Stride = 0, 
      StrideB = 0, Ptr = 0x0, Enabled = 0, Normalized = 0 '\0', 
      BufferObj = 0xa857788, _MaxElement = 0, Flags = 1}, {Size = 4, 
      Type = 5126, Stride = 0, StrideB = 0, Ptr = 0x0, Enabled = 0, 
      Normalized = 0 '\0', BufferObj = 0xa857788, _MaxElement = 0, Flags = 1}, 
    {Size = 4, Type = 5126, Stride = 0, StrideB = 0, Ptr = 0x0, Enabled = 0, 
      Normalized = 0 '\0', BufferObj = 0xa857788, _MaxElement = 0, Flags = 1}, 
    {Size = 4, Type = 5126, Stride = 0, StrideB = 0, Ptr = 0x0, Enabled = 0, 
      Normalized = 0 '\0', BufferObj = 0xa857788, _MaxElement = 0, Flags = 1}, 
    {Size = 4, Type = 5126, Stride = 0, StrideB = 0, Ptr = 0x0, Enabled = 0, 
      Normalized = 0 '\0', BufferObj = 0xa857788, _MaxElement = 0, 
      Flags = 1}}, EdgeFlag = {Size = 0, Type = 0, Stride = 0, StrideB = 0, 
    Ptr = 0x0, Enabled = 0, Normalized = 0 '\0', BufferObj = 0xa857788, 
    _MaxElement = 0, Flags = 1}, VertexAttrib = {{Size = 4, Type = 5126, 
      Stride = 0, StrideB = 0, Ptr = 0x0, Enabled = 0, Normalized = 0 '\0', 
      BufferObj = 0xa857788, _MaxElement = 0, Flags = 1} <repeats 32 times>}, 
  _Enabled = 1}

Ah, getting closer. Actually, actx->nr_vbos is monotonically increasing, after
it has passed 32 (VERT_ATTRIB_MAX), things will seriously blow up (that 23 for
actx->nr_vbos == 23 was wrong in the backtrace, as it got overwritten with
random data).

Another fix is in for this...  Hopefully the last one.

(In reply to comment #11)
> Ah, getting closer. Actually, actx->nr_vbos is monotonically increasing, after
> it has passed 32 (VERT_ATTRIB_MAX), things will seriously blow up (that 23 for
> actx->nr_vbos == 23 was wrong in the backtrace, as it got overwritten with
> random data).

Hmm, should actx->nr_vbos be set to 0 at the beginning of _ae_update_state? I've
tried that and I'm back to square one (_ae_invalidate_state: Assertion
`!actx->mapped_vbos' failed.). Argh...

(In reply to comment #13)
> tried that and I'm back to square one (_ae_invalidate_state: Assertion
> `!actx->mapped_vbos' failed.). Argh...

Ok, next backtrace:
#0  0x40017410 in ?? ()
#1  0xbfcd0e10 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00002fe4 in ?? ()
#4  0x4025c7a1 in raise () from /lib/tls/libc.so.6
#5  0x4025df79 in abort () from /lib/tls/libc.so.6
#6  0x40255fe3 in __assert_fail () from /lib/tls/libc.so.6
#7  0x4192cb9c in _ae_invalidate_state (ctx=0xa9bfd60, new_state=2)
    at main/api_arrayelt.c:1311
#8  0x419d0128 in _tnl_InvalidateState (ctx=0xa9bfd60, new_state=2)
    at tnl/t_context.c:158
#9  0x419d050b in _tnl_need_projected_coords (ctx=0xa9bfd60, mode=0 '\0')
    at tnl/t_context.c:251
#10 0x419036e9 in r200ChooseVertexState (ctx=0xa9bfd60) at r200_swtcl.c:279
#11 0x41900322 in r200UpdateTextureState (ctx=0xa9bfd60)
    at r200_texstate.c:1842
#12 0x418ef790 in r200ValidateState (ctx=0xa9bfd60) at r200_state.c:2576
#13 0x418ef9ec in r200WrapRunPipeline (ctx=0xa9bfd60) at r200_state.c:2668
#14 0x41a0b2ef in _tnl_flush_vtx (ctx=0xa9bfd60) at tnl/t_vtx_exec.c:281
#15 0x41a0037f in _tnl_wrap_buffers (ctx=0xa9bfd60) at tnl/t_vtx_api.c:84
#16 0x41a0046a in _tnl_wrap_filled_vertex (ctx=0xa9bfd60)
    at tnl/t_vtx_api.c:121
#17 0x41a04286 in attrib_0_3 (v=0x10e57c8c) at tnl/t_vtx_generic.c:100
#18 0x41a08703 in _tnl_Vertex3fv (v=0x10e57c8c) at tnl/t_vtx_generic.c:240
#19 0x4192cb2e in _ae_loopback_array_elt (elt=371) at main/api_arrayelt.c:1293
#20 0x41ae129f in fallback_drawelements (ctx=0xa9bfd60, mode=4, count=345, 
    indices=0x4c7a5170) at tnl/t_array_api.c:75
#21 0x41ae1b58 in _tnl_DrawElements (mode=4, count=345, type=5125, 
    indices=0x4c7a5170) at tnl/t_array_api.c:393
#22 0x08156450 in ?? ()
(sorry line numbers may not quite match as I've got some printfs in there). This
looks easier to figure out this time at least... And in any case, it now works
with tcl mode 1.

OK, I'm now pruning incoming state to the arrayelt code to just the two atoms of
interest.  Hopefully this will help.

Is it actually necessary to call _tnl_invalidate_state from
_tnl_need_projected_coords? Not calling it fixes this bug.

Indeed, the code which relied on that behaviour has since been removed, so it
would be OK to remove that call also.

This bug has been thoroughly beaten to death and hopefully stays dead.

Mass version move, cvs -> git