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
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
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
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:
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:
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
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).
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
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:
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:
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
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
