Re: [Bug 2516] some rasterization fallbacks cause segfaults

[Roland S. <rsc...@hi...>]

Keith Whitwell wrote:
> bug...@fr... wrote:
> 
>> Please do not reply to this email: if you want to comment on the bug, 
>> go to           the URL shown below and enter yourcomments there.     
>>    https://bugs.freedesktop.org/show_bug.cgi?id=2516              
>> anholt@FreeBSD.org changed:
>>
>>            What    |Removed                     |Added
>> ---------------------------------------------------------------------------- 
>>
>>              Status|NEW                         |ASSIGNED
>>
>>
>>
>>
>> ------- Additional Comments From anholt@FreeBSD.org  2005-05-31 15:21 
>> -------
>> I can reproduce a similar backtrace on radeon and r200 using 
>> neverball, which is
>> doing a rasterization fallback beacuse I'm running at 16bpp (no stencil).
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread -1214635360 (LWP 1346)]
>> 0xb70559a6 in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386
>> 386           a[j].inputptr = ((GLubyte *)vptr->data) + start * 
>> vptr->stride;
>> (gdb) bt
>> #0  0xb70559a6 in update_input_ptrs (ctx=0x0, start=0) at 
>> tnl/t_vertex.c:386
>> #1  0xb7055a52 in _tnl_build_vertices (ctx=0x8110180, start=0, end=0,
>> newinputs=4294967295)
>>     at tnl/t_vertex.c:408
>> #2  0xb704a066 in run_render (ctx=0x8110180, stage=0x830d314) at
>> tnl/t_vb_render.c:295
>> #3  0xb70410b5 in _tnl_run_pipeline (ctx=0x8110180) at 
>> tnl/t_pipeline.c:159
>> #4  0xb6fba915 in r200WrapRunPipeline (ctx=0x8110180) at 
>> r200_state.c:2316
>> #5  0xb704640c in _tnl_playback_vertex_list (ctx=0x8110180, 
>> data=0x85e5198)
>>     at tnl/t_save_playback.c:209
>> #6  0xb6feccb3 in execute_list (ctx=0x8110180, list=135332224) at 
>> main/dlist.c:5679
>> #7  0xb6fef760 in _mesa_CallList (list=80) at main/dlist.c:6747
>> #8  0xb703a9e2 in neutral_CallList (i=0) at vtxfmt_tmp.h:301
>>           
> 
> 
> For crashes involving the inputptr loop it is necessary to find and fix 
> the reason rather than just adding a guard.
See also comment #5. While the code has changed, as far as I can tell 
(didn't run a new debugging session) the reason stated there is still 
valid, i.e. there's a problem if the driver sets 
tnl_need_projected_coords to false while it's in a rasterization 
fallback. But I just don't understand the code well enough to see what 
really should be done about it...

> Presumably vptr is NULL 
> above, and the ctx=0x0 is just a gcc/gdb artifact.
Indeed.

Roland