Andreas Ehliar wrote:
>
> On Sun, Jan 16, 2000 at 03:18:22AM +0100, Andreas Ehliar wrote:
> > On Sun, Jan 16, 2000 at 02:14:37AM +0100, Andreas Ehliar wrote:
> > > I'm getting a segfault in lambda_textured_triangle1 while running
> > > Unreal Tournament. (Latest CVS, Mesa 3.2 branch, latest CVS of
> > > the Unreal Tournament renderer as well.)
> > >
> > > The segmentation fault is reproducable, it happens after a while in the
> > > demo that is running directly after starting up Unreal Tournament.
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x41de4baf in lambda_textured_triangle1 (ctx=0xa3064d8, v0=3, v1=483, v2=484,
> > > pv=5, s=0xbfffc9f4, t=0xbfffb0f4, u=0xbfff97f4) at tritemp.h:952
> > > 952 INNER_LOOP( left, right, iy );
> > > (gdb) p left
> > > $1 = -1047998
> > > Sounds pretty suspicious isn't it?
> > >
> > > Full backtrace:
> > > #0 0x41de4baf in lambda_textured_triangle1 (ctx=0xa3064d8, v0=3, v1=483,
> > > v2=484, pv=5, s=0xbfffc9f4, t=0xbfffb0f4, u=0xbfff97f4) at tritemp.h:952
> > > #1 0x41deb54b in lambda_textured_triangle (ctx=0xa3064d8, v0=3, v1=483,
> > > v2=484, pv=5) at triangle.c:1432
> > > #2 0x41df9162 in gl_render_clipped_triangle2 (ctx=0xa3064d8, v1=3, v2=4,
> > > v3=5, pv=5) at vbrender.c:242
> > > #3 0x41df84ad in render_vb_tri_fan_clipped (VB=0xa318ce8, start=3, count=6,
> > > parity=0) at render_tmp.h:181
> > > #4 0x41df8c03 in gl_render_vb () at render_tmp.h:274
> > > #5 0x41d7af39 in gl_run_pipeline () at pipeline.c:395
> > > #6 0x41dfc9ed in gl_execute_cassette () at vbxform.c:811
> > > #7 0x41d0f935 in gl_cva_compile_cassette () at cva.c:189
> > > #8 0x41df9219 in gl_maybe_transform_vb () at vbxform.c:188
> > > #9 0x41df92b9 in gl_flush_vb () at vbxform.c:188
> > > #10 0x41cdab66 in gl_BlendFunc () at blend.c:212
> > > #11 0x41cc6580 in glBlendFunc () at api1.c:1647
> > > #12 0x412aa4e6 in UXMesaGLRenderDevice::DrawComplexSurface ()
> > > from /.2/ut/System/XMesaGLDrv.so
> > > #13 0x40ade4a4 in URender::DrawFrame () from /.2/ut/System/Render.so
> > > #14 0x40adff3f in URender::DrawWorld () from /.2/ut/System/Render.so
> > > #15 0xc8 in ?? ()
> >
> > I did a bit more research and found that I am getting garbage in
> > VB->Win.data[vMid][0]:
> >
> > (gdb) p VB->Win.data[vMid][0]
> > $7 = -NaN(0x400000)
> >
>
> Aha, I think that I have found it.
> With sanity-check.diff applied I get the following output:
> general_clip.h:viewclip_polygon_4: Sanity check failed at line 109:
> general_clip.h:viewclip_polygon_4: Y(out) is 394.594452, Y(in) is 81.216568, dy is
>313.377869
> general_clip.h:viewclip_polygon_4: W(out) is 394.594421, W(in) is 81.216568, dw is
>313.377869
> general_clip.h:viewclip_polygon_4: Y(in)-W(in) is 0.000000, dw-dy is 0.000000
> general_clip.h:viewclip_polygon_4: t is nan,neww is nan
>
> And the attached file general-clip.diff seems to fix the problem.
>
I think the real problem occurs earlier - the question is how to avoid trying
to interpolate between these two colocated points. Your patch cleans up
afterwards, and slows down the normal case.
Can I ask a few things about this triangle:
It seems to cross more than one clip plane, is this correct? (What is the
ClipOrMask?)
Maybe it is initially degenerate - can you trace back and find what the
original clip coordinates were?
Is it possible to track the coordinates which were generated by each round of
clipping?
Keith
_______________________________________________
Mesa-bug maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-bug
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
