Re: [Dri-devel] Mesa / DRI r200 crashes
OK, perhaps you could check in the restored version for now. I may not get to look into this further for a day or two. -Brian Oh - such a drastic measure :-(. Is there some way to revert changes in cvs, or do I just have to submit that as a new version, maybe even with tricks like update it (with -r), then locally remove the revision tag in the CVS Entries file and commit it? I don't want to hose the cvs repository... Sorry, nevermind. I think I've figured it out. Roland --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
Brian Paul wrote: Roland Scheidegger wrote: Brian Paul wrote: 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 = 20, 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 = 20, 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 This indeed fixes the crash in both the ut intro and ut2003 startup. OK, perhaps you could check in the restored version for now. I may not get to look into this further for a day or two. -Brian Oh - such a drastic measure :-(. Is there some way to revert changes in cvs, or do I just have to submit that as a new version, maybe even with tricks like update it (with -r), then locally remove the revision tag in the CVS Entries file and commit it? I don't want to hose the cvs repository... Roland --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
Roland Scheidegger wrote: Brian Paul wrote: 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 = 20, 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 = 20, 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 This indeed fixes the crash in both the ut intro and ut2003 startup. OK, perhaps you could check in the restored version for now. I may not get to look into this further for a day or two. -Brian --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
Brian Paul wrote: 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 = 20, 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 = 20, 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 This indeed fixes the crash in both the ut intro and ut2003 startup. Roland --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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 = 20, 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 = 20, 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). If you compile without -O2 (edit host.def), these problems should go away. Keith --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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 = > >>> 20, 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 = 20, 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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 = 20, 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 = 20, 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 -Brian --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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 = 20, 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 = 20, 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. --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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 = 20, 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 = 20, 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? -Brian --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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 = 20, 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 = 20, Flags = 1} Roland --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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'? 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]. -Brian --- 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
Re: [Dri-devel] Mesa / DRI r200 crashes
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. Keith --- 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
[Dri-devel] Mesa / DRI r200 crashes
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 #5 0x3bf87c9b in ?? () #6 0x3b76509b in ?? () #7 0x3b76734f in ?? () #8 0x3ac4e058 in ?? () #9 0x3b71d44b in ?? () #10 0x3b71a477 in ?? () #11 0x3ac51926 in ?? () #12 0x0804d3fe in _start () #13 0x0804e29d in main () #14 0x3b0e24c2 in __libc_start_main () from /lib/i686/libc.so.6 In the ut case, the problems seems to vanish when using tcl_mode=0 or tcl_mode=1, though I believe it's the same problem which causes ut2003 not to run at all (regardless the tcl mode). Roland --- 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