Bug 4842

Summary: Segment Fault on 64-bit offscreen render for primitive render due to improper span creation
Product: Mesa Reporter: James Burns <James.Burns>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: highest    
Version: 6.2.1   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description James Burns 2005-10-21 10:33:44 UTC
Problem 1 - CRASH

CSG/IFS/MESA CRASH Resolution 10/21/05

 

ISSUE: MESA segment fault in depth test.

 

CONTEXT: Opteron 64 bit static build.  Other 64 bit builds may be susceptible 
also.

 

CAUSE:   The creation on an invalid span during the rasterization of primitives

 

CORRECTION: If a bad span is created, prevent it from being rendered: see code

 

               if ((span.end > 0) && (span.y > 0)) {

                  RENDER_SPAN( span );

               }

 

 

 


 

Originally CSG would segment fault in depth_test_span32.  The z-buffer pointer 
was the invalid pointer.  This was due to the fact that the depth_test_span 
function was calling the Z_ADDRESS32 macro with a y parameter value of -1, 
which resulted in the return of an invalid pointer, which was passed down to 
the depth_test_span32 function.  The y=-1 come from file s_tritemp.h where 
primitives are rasterized as spans and passed down for rendering.  
Infrequently, in 64-bit mode, it is possible for a span to be generated 
outside of the window/viewing area, causing the anomaly.

 

Data supporting this is below.

 

 

ORIGINAL SYMPTOMS:

 

backtrace: The scene generation program actually goes up to reach a total of 37

call stack frames, but this call stack should give enough to see the problem.

 

#0  0x0000002a970cf39f in depth_test_span32 (ctx=0x2a9b74e010, n=94,

    zbuffer=0x2e9c102200, z=0x2a9b794010,

    mask=0x2a9b840010 '\001' <repeats 99 times>) at swrast/s_depth.c:315

#1  0x0000002a970cfbe0 in depth_test_span (ctx=0x2a9b74e010, span=0x7fbfffa770)

    at swrast/s_depth.c:568

#2  0x0000002a970d19de in _swrast_depth_test_span (ctx=0x2a9b74e010,

    span=0x7fbfffa770) at swrast/s_depth.c:1361

#3  0x0000002a970e0323 in _swrast_write_texture_span (ctx=0x2a9b74e010,

    span=0x7fbfffa770) at swrast/s_span.c:1426

#4  0x0000002a9710e77b in multitextured_triangle (ctx=0x2a9b74e010,

    v0=0x2a9b8838dc, v1=0x2a9b883784, v2=0x2a9b883580) at s_tritemp.h:1181

#5  0x0000002a970ce520 in _swrast_Triangle (ctx=0x2a9b74e010, v0=0x2a9b8838dc,

    v1=0x2a9b883784, v2=0x2a9b883580) at swrast/s_context.c:528

#6  0x0000002a9711cdf6 in triangle_rgba (ctx=0x2a9b74e010, e0=13, e1=11, e2=8)

    at ss_tritmp.h:145

#7  0x0000002a970aa498 in _tnl_render_poly_elts (ctx=0x2a9b74e010, start=0,

    count=5, flags=48) at t_vb_rendertmp.h:322

#8  0x0000002a970aaa65 in _tnl_RenderClippedPolygon (ctx=0x2a9b74e010,

    elts=0x7fbfffad60, n=5) at tnl/t_vb_render.c:249

#9  0x0000002a970b2b25 in clip_quad_4 (ctx=0x2a9b74e010, v0=0, v1=1, v2=2,

    v3=3, mask=63 '?') at t_vb_cliptmp.h:260

#10 0x0000002a970a5dd1 in clip_render_quads_verts (ctx=0x2a9b74e010, start=0,

    count=4, flags=119) at t_vb_rendertmp.h:347

#11 0x0000002a970aac75 in run_render (ctx=0x2a9b74e010, stage=0x92eae8)

    at tnl/t_vb_render.c:326

#12 0x0000002a9708aa5d in _tnl_run_pipeline (ctx=0x2a9b74e010)

    at tnl/t_pipeline.c:159

#13 0x0000002a97093d03 in _tnl_playback_vertex_list (ctx=0x2a9b74e010,

    data=0x26c4468) at tnl/t_save_playback.c:217

#14 0x0000002a96ff6b76 in execute_list (ctx=0x2a9b74e010, list=112)

    at main/dlist.c:5357

#15 0x0000002a96ffa7f9 in _mesa_CallList (list=112) at main/dlist.c:6360

#16 0x0000002a96fb7c8d in glCallList (list=112) at glapitemp.h:86

#17 0x0000002a98df3d1d in osg::Drawable::draw(osg::State&) const ()

   from /home/burnsje/EIFS/ver1.1/csg124/OSG_OP_OT-0.9.8-
2/OpenSceneGraph/lib/Linux64/libosgUtil.so

#18 0x0000002a98df3932 in osgUtil::RenderLeaf::render(osg::State&, 
osgUtil::RenderLeaf*) ()

 

 

Vertex/primitive data to be rendered/rasterized/spaned -

(gdb) p *v0

$20 = {win = {748.545349, -0.0446777344, 2.14748365e+09, 0.000199493777},

  texcoord = {{0.680000007, 0.001953125, 0, 1}, {6615.25, 283.3125, 50, 1}, {

      6615.25, 283.3125, 50, 1}, {6680.75, 278.617188, 50, 1}, {0, 0, 0, 0}, {

      0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}}, color = {65535, 65535, 65535,

    65535}, specular = {0, 0, 0, 0}, fog = 0, index = 0, pointSize = 0}

(gdb) p *v1

$21 = {win = {0.0755310059, -0.528869629, 2.12419302e+09, 0.00236092671},

  texcoord = {{0.639999986, 0.001953125, 0, 1}, {2054.8125, -123.1875, 50, 1},

    {2054.8125, -123.1875, 50, 1}, {2055.6875, -126.3125, 50, 1}, {0, 0, 0,

      0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}}, color = {65535, 65535,

    65535, 65535}, specular = {0, 0, 0, 0}, fog = 0, index = 0, pointSize = 0}

(gdb) p *v2

$22 = {win = {1023.97931, 1024, 2.14272077e+09, 0.000643756997}, texcoord = {{

      0.600000024, 0.0399999991, 0, 1}, {3304.03174, -492.18634, 50, 1}, {

      3304.03174, -492.18634, 50, 1}, {3193.14014, -470.173981, 50, 1}, {0, 0,

      0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}}, color = {65535, 65535,

    65535, 65535}, specular = {0, 0, 0, 0}, fog = 0, index = 0, pointSize = 0}
Comment 1 Brian Paul 2005-10-21 11:17:10 UTC
Any chance of getting a small test program to reproduce this?
We really shouldn't be generating vertices with Y<0 if the viewport's Y position
is zero.

PS: submit future bugs on freedesktop.org
Comment 2 Brian Paul 2005-10-21 11:17:54 UTC
Ugh, ignore my last comment about bugs on freedesktop.org :)
Comment 3 Brian Paul 2005-10-21 11:36:38 UTC
I've checked in your fix, though the test should be y>=0, not y>0.
A test program to find a better fix would still be nice.
Comment 4 James Burns 2005-10-24 07:16:14 UTC
Will this correction be included in Mesa 6.4?
Comment 5 Brian Paul 2005-10-24 07:27:38 UTC
Yes, the fix will be in 6.4
Comment 6 Brian Paul 2006-01-20 01:54:01 UTC
This was fixed in 6.4.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.