Am Dienstag, 10. Februar 2004 23:35 schrieb Brian Paul:
> Roland Scheidegger wrote:
> > Brian Paul wrote:
> >> Roland Scheidegger wrote:
> >>> Brian Paul wrote:
> >>>> Keith Whitwell wrote:
> >>>>> Roland Scheidegger wrote:
> >>>>>> I get a lot of dri crashes, were there some changes very recently
> >>>>>> in the tnl code? The crashes sometimes are predictable (for
> >>>>>> instance in the old ut it'll always crash in the intro when the
> >>>>>> announcer says "in twenty-two ninety-" segfault!)
> >>>>>> gdb says this:
> >>>>>> Program received signal SIGSEGV, Segmentation fault.
> >>>>>> [Switching to Thread 1024 (LWP 4566)]
> >>>>>> 0x458bce72 in ?? ()
> >>>>>> (gdb) bt
> >>>>>> #0 0x458bce72 in ?? ()
> >>>>>> #1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4)
> >>>>>> at vtxfmt_tmp.h:384
> >>>>>> #2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
> >>>>>> api_arrayelt.c:828
> >>>>>> #3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
> >>>>>> start=29, count=34) at t_array_api.c:57
> >>>>>> #4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
> >>>>>> count=171564768) at t_array_api.c:153
> >>>>>
> >>>>> This looks like something which Brian has been working on recently.
> >>>>
> >>>> Roland, can you back up to _ae_loopback_array_elt() and 'print
> >>>> *at->array'?
> >>>
> >>> Certainly.
> >>> #2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
> >>> 828 at->func( at->index, src );
> >>> (gdb) print *at->array
> >>> $1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
> >>> 0xa38104c "�\005\202?�\005\202?", Enabled = 1,
> >>> Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
> >>> 2000000000, Flags = 1}
> >>>
> >>>> My guess is that the src pointer is invalid for some reason. The
> >>>> pointer arithmetic looks OK though.
> >>>>
> >>>> Basically, the glArrayElement() fallback code wasn't handling
> >>>> glVertexAttrib arrays. I added that and expressed the
> >>>> multi-texcoord arrays in terms of vertex attribs. Vertex attribute
> >>>> 9 corresponds to texcoord array 1.
> >>>>
> >>>> In gdb, also check if at->array == ctx->Array.TexCoord[1].
> >>>
> >>> #2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
> >>> 828 at->func( at->index, src );
> >>> (gdb) print at->array
> >>> $4 = (const struct gl_client_array *) 0xa3b2c38
> >>> (gdb) print ctx->Array.TexCoord[1]
> >>> Cannot access memory at address 0x14d89
> >>> (2 levels up)
> >>> #4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
> >>> at t_array_api.c:153
> >>> 153 fallback_drawarrays( ctx, mode, start, start + count );
> >>> (gdb) print ctx->Array.TexCoord[1]
> >>> $5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
> >>> 0xa381054 "", Enabled = 1, Normalized = 0 '\0',
> >>> BufferObj = 0xa39aae0, _MaxElement = 2000000000, Flags = 1}
> >>
> >> Two things:
> >>
> >> 1. It's strange that ctx->Array.TexCoord[1] is an invalid address in
> >> _ae_loopback_array_elt() but valid in _tnl_DrawArrays().
> >>
> >> 2. The count parameter to _tnl_DrawArrays() is _really_ large. What's
> >> up with that?
> >
> > I believe both problems are just debugger problems. I know I've seen the
> > second problem quite a few times (the debugger just seems to fail to
> > grab the right value for parameters in the function parameter list,
> > possibly due to optimizations?). And I believe the first problem can
> > also happen just because of the debugger (btw it's gdb 5.2.1 and gcc
> > 3.2, it might be better nowadays).
> >
> > Roland
> > btw if you haven't already seen it, Andreas report on ut2003/radeon
> > crash looks to me like it's a very related problem.
>
> Try reverting api_arrayelt.c to version 1.18 and see what happens:
>
> cvs update -r 1.18 api_arrayelt.c
Have a look at my post
'Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps',
please.
Sorry, I got relay denied so I've postet twice.
Greetings,
Dieter
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
