[r200] radeon dri and blender in gutsy

Bug #174479 reported by cellstije
8
Affects Status Importance Assigned to Milestone
Mesa
Fix Released
Medium
mesa (Ubuntu)
Fix Released
Undecided
Unassigned
xserver-xorg-video-ati (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

hi,

I am having issues with blender 2.44 (gutsy) using the radeon dri drivers.

The card is a sapphire radeon 9250 with 128MB.
lspci reports the following:
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)

Blender shows often (but not always) rendering errors while modelling.
Moreover if i switch to camera (0/ins key on the numeric pad) the center of the view is black.
Finally it tends to crash if i try to move away form camera mode (hitting key 7 or key 3 on the numeric pad).
The crash is reproduceable easily.
Below the output of gdb:

(gdb) file /usr/bin/blender-bin
Reading symbols from /usr/bin/blender-bin...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/blender-bin
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1225237840 (LWP 7028)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Compiled with Python version 2.5.1.
Checking for installed Python... got it!
(no debugging symbols found)
(no debugging symbols found)
Ignoring Xlib error: error code 171 request code 147
Ignoring Xlib error: error code 171 request code 147
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225237840 (LWP 7028)]
0xb6c977c5 in ?? () from /usr/lib/dri/r200_dri.so
(gdb) bt
#0 0xb6c977c5 in ?? () from /usr/lib/dri/r200_dri.so
#1 0xffffffff in ?? ()
#2 0x00000001 in ?? ()
#3 0xbfa34058 in ?? ()
#4 0xb6c8e9a4 in r200UpdateTextureState () from /usr/lib/dri/r200_dri.so
#5 0xb6d28835 in ?? () from /usr/lib/dri/r200_dri.so
#6 0x08b12a88 in ?? ()
#7 0x00000001 in ?? ()
#8 0x00000002 in ?? ()
#9 0x00000000 in ?? ()
(gdb)

I found a similar problem reported way back:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/24810

but not sure if related

Best
m.

Revision history for this message
In , Aurélien PROVIN (aprovin) wrote :

Created an attachment (id=11277)
Xorg.0.log

Revision history for this message
In , Alberto Luaces (azdo-b) wrote :
Download full text (3.7 KiB)

Same problem here with a Thinkpad R51 laptop, Radeon Mobility 7500 (M7 LW), Debian Lenny. Looking at the stack trace, it seems a problem exists with VBOs, maybe they are not yet correctly implemented in the driver. However, there is not a way for me to disable them in Blender.

My stack trace seems to show that a recursive bug is overflowing the stack:

#0 0xb73ad64a in _tnl_draw_prims () from /usr/lib/dri/radeon_dri.so
#1 0xb7452e71 in vbo_split_copy () from /usr/lib/dri/radeon_dri.so
#2 0xb745337e in vbo_split_inplace () from /usr/lib/dri/radeon_dri.so
#3 0xb73ad799 in _tnl_draw_prims () from /usr/lib/dri/radeon_dri.so
#4 0xb7452e71 in vbo_split_copy () from /usr/lib/dri/radeon_dri.so
#5 0xb745337e in vbo_split_inplace () from /usr/lib/dri/radeon_dri.so
#6 0xb73ad799 in _tnl_draw_prims () from /usr/lib/dri/radeon_dri.so

...

#26654 0x08356a90 in screenmain () at /home/alberto/blender-2.44/source/blender/src/editscreen.c:1502
1502 /home/alberto/blender-2.44/source/blender/src/editscreen.c: No existe el fichero o el directorio.
        in /home/alberto/blender-2.44/source/blender/src/editscreen.c
(gdb)
#26653 0x0835606c in screen_dispatch_events () at /home/alberto/blender-2.44/source/blender/src/editscreen.c:1223
1223 in /home/alberto/blender-2.44/source/blender/src/editscreen.c
(gdb)
#26652 0x083545ef in scrarea_dispatch_events (sa=0x8f14790) at /home/alberto/blender-2.44/source/blender/src/editscreen.c:608
608 in /home/alberto/blender-2.44/source/blender/src/editscreen.c
(gdb)
#26651 0x084c2597 in scrarea_do_windraw (area=0x8f14790) at /home/alberto/blender-2.44/source/blender/src/spacetypes.c:115
115 /home/alberto/blender-2.44/source/blender/src/spacetypes.c: No existe el fichero o el directorio.
        in /home/alberto/blender-2.44/source/blender/src/spacetypes.c
(gdb)
#26650 0x082a3800 in drawview3dspace (sa=0x8f14790, spacedata=0x8f14aa8) at /home/alberto/blender-2.44/source/blender/src/drawview.c:2852
2852 /home/alberto/blender-2.44/source/blender/src/drawview.c: No existe el fichero o el directorio.
        in /home/alberto/blender-2.44/source/blender/src/drawview.c
(gdb)
#26649 0x083d1a02 in draw_object (base=0x8fa1c50, flag=0) at /home/alberto/blender-2.44/source/blender/src/drawobject.c:3919
3919 /home/alberto/blender-2.44/source/blender/src/drawobject.c: No existe el fichero o el directorio.
        in /home/alberto/blender-2.44/source/blender/src/drawobject.c
(gdb)
#26648 0x083ccd4b in draw_mesh_object (base=0x8fa1c50, dt=3, flag=0) at /home/alberto/blender-2.44/source/blender/src/drawobject.c:2196
2196 in /home/alberto/blender-2.44/source/blender/src/drawobject.c
(gdb)
#26647 0x083cc4e6 in draw_mesh_fancy (base=0x8fa1c50, dt=3, flag=0) at /home/alberto/blender-2.44/source/blender/src/drawobject.c:2041
2041 in /home/alberto/blender-2.44/source/blender/src/drawobject.c
(gdb)
#26646 0x086b1d78 in cdDM_drawFacesSolid (dm=0x8ffd3c8, setMaterial=0x83c68ec <set_gl_material>)
    at /home/alberto/blender-2.44/source/blender/blenkernel/intern/cdderivedmesh.c:299
299 /home/alberto/blender-2.44/source/blender/blenkernel/intern/cdderivedmesh.c: No existe el fichero o el directorio.
        in /home/a...

Read more...

Revision history for this message
In , Brian-paul (brian-paul) wrote :

Alberto, could you try a debug build of Mesa to get a stack trace with function arguments?

If you can provide detailed instructions on how to reproduce this I'll give it a try. I don't know how to use Blender otherwise.

Revision history for this message
In , Alberto Luaces (azdo-b) wrote :
Download full text (6.1 KiB)

Hello Brian, thank you for your help. Here I send the stack trace with arguments.

The way to reproduce the crash in Blender is easy:

1-Open Blender
2-Hit the space bar. A menu will be shown. Select from the menu: Add->Mesh->UVSphere. Accept the defaults clicking on "OK".
3-Now you are on "edit mode". Hit TAB to "exit edit mode"...
4-Crash

Here are the last frames of the stack trace:

#0 0xb741ff82 in vbo_split_inplace (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf041234, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb737a630 <_tnl_draw_prims>, limits=0xbf0410f8) at vbo/vbo_split_inplace.c:271
#1 0xb737a799 in _tnl_draw_prims (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf041234, nr_prims=15, ib=0x0, min_index=0, max_index=910) at tnl/t_draw.c:384
#2 0xb741fe71 in flush_vertex (split=0xbf041210) at vbo/vbo_split_inplace.c:99
#3 0xb742037e in vbo_split_inplace (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf0415e4, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb737a630 <_tnl_draw_prims>, limits=0xbf0414a8) at vbo/vbo_split_inplace.c:255
#4 0xb737a799 in _tnl_draw_prims (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf0415e4, nr_prims=15, ib=0x0, min_index=0, max_index=910) at tnl/t_draw.c:384
#5 0xb741fe71 in flush_vertex (split=0xbf0415c0) at vbo/vbo_split_inplace.c:99
#6 0xb742037e in vbo_split_inplace (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf041994, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb737a630 <_tnl_draw_prims>, limits=0xbf041858) at vbo/vbo_split_inplace.c:255
#7 0xb737a799 in _tnl_draw_prims (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf041994, nr_prims=15, ib=0x0, min_index=0, max_index=910) at tnl/t_draw.c:384
#8 0xb741fe71 in flush_vertex (split=0xbf041970) at vbo/vbo_split_inplace.c:99
#9 0xb742037e in vbo_split_inplace (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf041d44, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb737a630 <_tnl_draw_prims>, limits=0xbf041c08) at vbo/vbo_split_inplace.c:255
#10 0xb737a799 in _tnl_draw_prims (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf041d44, nr_prims=15, ib=0x0, min_index=0, max_index=910) at tnl/t_draw.c:384
#11 0xb741fe71 in flush_vertex (split=0xbf041d20) at vbo/vbo_split_inplace.c:99
#12 0xb742037e in vbo_split_inplace (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf0420f4, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb737a630 <_tnl_draw_prims>, limits=0xbf041fb8) at vbo/vbo_split_inplace.c:255
#13 0xb737a799 in _tnl_draw_prims (ctx=0x8e45df0, arrays=0xbf83effc, prim=0xbf0420f4, nr_prims=15, ib=0x0, min_index=0, max_index=910) at tnl/t_draw.c:384
#14 0xb741fe71 in flush_vertex (split=0xbf0420d0) at vbo/vbo_split_inplace.c:99

...and here are the first frames where Blender calls OpenGL:

#26641 0x083d1a02 in draw_object (base=0x8ee64a0, flag=0) at /home/alberto/blender-2.44/source/blender/src/drawobject.c:3919
3919 /home/alberto/blender-2.44/source/blender/src/drawobject.c: No existe el fichero o el directorio.
        in /home/alberto/blender-2.44/source/blender/src/drawobject.c
(gdb)
#26640 0x083ccd4b in draw_mesh_object (base=0x8ee64a0, dt=3, flag=0) at /home/alberto/blender-2.44/source/blender/src/drawobject.c:21...

Read more...

Revision history for this message
In , Aurélien PROVIN (aprovin) wrote :
Download full text (5.1 KiB)

Blender 2.45 released.

The bug is still present :

Starting program: /usr/bin/blender-bin
[Thread debugging using libthread_db enabled]
[New Thread 0xb6e90a00 (LWP 13443)]
Compiled with Python version 2.4.4.
Checking for installed Python... got it!

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6e90a00 (LWP 13443)]
triangle_twoside (ctx=0x8ad4680, e0=1, e1=2, e2=0)
    at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:202
202 ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h: No such file or directory.
        in ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h

----------------------------------------------------------------------------

(gdb) bt
#0 triangle_twoside (ctx=0x8ad4680, e0=1, e1=2, e2=0)
    at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:202
#1 0xb6b4f265 in _tnl_render_poly_verts (ctx=0x8ad4680, start=0, count=32,
    flags=57) at tnl/t_vb_rendertmp.h:313
#2 0xb6b502c2 in run_render (ctx=0x8ad4680, stage=0x8b244dc)
    at tnl/t_vb_render.c:320
#3 0xb6b47a9b in _tnl_run_pipeline (ctx=0x8ad4680) at tnl/t_pipeline.c:158
#4 0xb6b47f73 in _tnl_draw_prims (ctx=0x8ad4680, arrays=0x8b12700,
    prim=0x8b1125c, nr_prims=1, ib=0x0, min_index=0, max_index=31)
    at tnl/t_draw.c:403
#5 0xb6b41176 in vbo_exec_vtx_flush (exec=0x8b11138)
    at vbo/vbo_exec_draw.c:215
#6 0xb6b3cf88 in vbo_exec_wrap_buffers (exec=0x8b11138)
    at vbo/vbo_exec_api.c:80
#7 0xb6b3d0ad in vbo_exec_fixup_vertex (ctx=<value optimized out>, attr=3,
    sz=3021070384) at vbo/vbo_exec_api.c:218
#8 0xb6b3ff54 in vbo_Color4f (x=0, y=0, z=0, w=0.882353008)
    at vbo/vbo_attrib_tmp.h:163
#9 0x081a6424 in BIF_ThemeColorShadeAlpha ()
#10 0x082a390d in drawcentercircle ()
#11 0x082a6b5d in draw_object ()
#12 0x08143166 in drawview3dspace ()
#13 0x08169585 in scrarea_do_windraw ()
---Type <return> to continue, or q <return> to quit---
#14 0x08173696 in screenmain ()
#15 0x081365e7 in main ()
(gdb)

-------------------------------------------------------------------------

(gdb) bt full
#0 triangle_twoside (ctx=0x8ad4680, e0=1, e1=2, e2=0)
    at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:202
        vbcolor = <value optimized out>
        VB = (struct vertex_buffer *) 0x8b24708
        rmesa = (radeonContextPtr) 0x8acb650
        coloroffset = 3
        specoffset = 0
#1 0xb6b8a265 in _tnl_render_poly_verts (ctx=0x8ad4680, start=0, count=32,
    flags=57) at tnl/t_vb_rendertmp.h:313
        efstart = <value optimized out>
        efcount = <value optimized out>
        j = 3
        tnl = (TNLcontext *) 0x8b242c8
        VB = <value optimized out>
        TriangleFunc = (const tnl_triangle_func) 0xb6af7000 <triangle_twoside>
        stipple = 0 '\0'
#2 0xb6b8b2c2 in run_render (ctx=0x8ad4680, stage=0x8b244dc)
    at tnl/t_vb_render.c:320
        prim = 3021312048
        start = 0
        length = <value optimized out>
        i = 1
        tnl = (TNLcontext *) 0x8b242c8
---Type <return> to continue, or q <return> to quit---
        VB = (struct vertex_buffer *) 0x8b24708
        tab = (tnl_render_func *) 0xb6c9e9a0
        pass = 0
        __PRETTY_FUNCTION__ = "run_render"
#3 0xb6b82a9b in _tnl_run_pipeline (ctx=0x8ad4680) at ...

Read more...

Revision history for this message
In , Brian-paul (brian-paul) wrote :

Created an attachment (id=11687)
emit debug info in t_dd_tritmp.h

I don't have an r200 to test with and I haven't been able to make blender crash with software rendering (Xlib driver).

It looks like you've found crashes into two totally different places. Can you explain what you're doing differently in those two cases?

Can you apply this patch to src/mesa/tnl_dd/t_dd_tritmp.h, recompile your r200 driver, then re-run blender? If you hit the problem in triangle_twoside() it should print some debug info that might help me.

Revision history for this message
In , Aurélien PROVIN (aprovin) wrote :
Download full text (3.7 KiB)

I have apply your patch but there is an error during build (no member
'LightModel'). So I have "disable" this line. I re-run blender. Blender crash at startup (I do nothing particular, I just run blender and it crash immediately)

(gdb) run
Starting program: /usr/bin/blender-bin
[Thread debugging using libthread_db enabled]
[New Thread 0xb6ed5a00 (LWP 11561)]
Compiled with Python version 2.4.4.
Checking for installed Python... got it!
Mesa Problem in triangle_twoside: ColorPtr[1]==NULL
  Light.Enabled=0
  TriangleCaps=0x1

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6ed5a00 (LWP 11561)]
0xb71b77d6 in raise () from /lib/libc.so.6
(gdb)

#0 0xb71b77d6 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0xb71b90f1 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0xb6b042d3 in triangle_twoside (ctx=0x8ad4680, e0=1, e1=2, e2=0)
    at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:213
        vbcolor = <value optimized out>
        rmesa = (radeonContextPtr) 0x8acb650
        coloroffset = 3
        specoffset = 0
        __FUNCTION__ = "triangle_twoside"
#3 0xb6b95b0e in _tnl_render_poly_verts (ctx=0x8ad4680, start=0, count=32,
    flags=57) at tnl/t_vb_rendertmp.h:313
        efstart = <value optimized out>
        efcount = <value optimized out>
        j = 3
        tnl = (TNLcontext *) 0x8b242c8
        TriangleFunc = (const tnl_triangle_func) 0xb6b03360 <triangle_twoside>
        stipple = 0 '\0'
#4 0xb6b96bb1 in run_render (ctx=0x8ad4680, stage=0x8b244dc)
    at tnl/t_vb_render.c:320
        prim = 11561
        start = 0
---Type <return> to continue, or q <return> to quit---
        length = <value optimized out>
        i = 0
        tnl = (TNLcontext *) 0x8b242c8
        tab = (tnl_render_func *) 0xb6ca89a0
        pass = 0
        __PRETTY_FUNCTION__ = "run_render"
#5 0xb6b8e71f in _tnl_run_pipeline (ctx=0x8ad4680) at tnl/t_pipeline.c:158
        tnl = (TNLcontext *) 0x8b242c8
        __tmp = 895
        i = 8
        mask = 63
#6 0xb6b8ec63 in _tnl_draw_prims (ctx=0x8ad4680, arrays=0x8b12700,
    prim=0x8b1125c, nr_prims=1, ib=0x0, min_index=0, max_index=31)
    at tnl/t_draw.c:403
        bo = {0x1, 0x8b142d8, 0x0, 0x0, 0x0, 0xbfc15464, 0x0, 0xb75a9a98,
  0x8ad4680, 0x8ad4680, 0x8b109f8, 0x8b11138, 0xbfc154a0, 0xb7f57668,
  0x8af2f10, 0x8af2cf0, 0xbfc15408, 0xb6b7c844, 0x8af2f80, 0xb6ca8920, 0x40,
  0x0, 0x4, 0x25, 0xbfc15428, 0xb6b7c626, 0x8af2cf0, 0x8acb650, 0xbfc15438,
  0xb6b83e0e, 0x8ad4680, 0x84217bde, 0xbfc15468}
        nr_bo = 0
        tnl = (TNLcontext *) 0x8b242c8
#7 0xb6b8833b in vbo_exec_vtx_flush (exec=0x8b11138)
    at vbo/vbo_exec_draw.c:215
---Type <return> to continue, or q <return> to quit---
        ctx = (GLcontext *) 0x8ad4680
#8 0xb6b84538 in vbo_exec_wrap_buffers (exec=0x8b11138)
    at vbo/vbo_exec_api.c:80
        last_count = 32
        __PRETTY_FUNCTION__ = "vbo_exec_wrap_buffers"
#9 0xb6b8466c in vbo_exec_fixup_vertex (ctx=<value optimized out>, attr=3,
    sz=11561) at vbo/vbo_exec_api.c:218
        exec = (struct vbo_exec_context *) 0x8b11138
        i = <value optimized out>
        id = {0, 0, 0, 1}
#10 0xb6b8711e in vbo_Color4f...

Read more...

Revision history for this message
In , Brian-paul (brian-paul) wrote :

Created an attachment (id=11693)
r200ChooseRenderState patch

Here's another patch to try.

Revision history for this message
In , Aurélien PROVIN (aprovin) wrote :
Download full text (3.8 KiB)

I think my card doesn't use r200 driver but radeon driver...
The result of 2 patch :

(gdb) run
Starting program: /usr/bin/blender-bin
[Thread debugging using libthread_db enabled]
[New Thread 0xb6e85a00 (LWP 5311)]
Compiled with Python version 2.4.4.
Checking for installed Python... got it!
Mesa Problem in triangle_twoside: ColorPtr[1]==NULL
  Light.Enabled=0
  Light.TwoSide=1
  TriangleCaps=0x1

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6e85a00 (LWP 5311)]
0xb71677d6 in raise () from /lib/libc.so.6

(gdb) bt full
#0 0xb71677d6 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0xb71690f1 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0xb6ab1b9c in triangle_twoside (ctx=0x8ad5eb0, e0=1, e1=2, e2=0)
    at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:213
        vbcolor = <value optimized out>
        VB = (struct vertex_buffer *) 0x8b25f48
        rmesa = (radeonContextPtr) 0x8accec8
        coloroffset = 3
        specoffset = 0
        __FUNCTION__ = "triangle_twoside"
#3 0xb6b441a5 in _tnl_render_poly_verts (ctx=0x8ad5eb0, start=0, count=32,
    flags=57) at tnl/t_vb_rendertmp.h:313
        efstart = <value optimized out>
        efcount = <value optimized out>
        j = 3
        tnl = (TNLcontext *) 0x8b25b08
        VB = <value optimized out>
        TriangleFunc = (const tnl_triangle_func) 0xb6ab0fd0 <triangle_twoside>
        stipple = 0 '\0'
#4 0xb6b45202 in run_render (ctx=0x8ad5eb0, stage=0x8b25d1c)
    at tnl/t_vb_render.c:320
---Type <return> to continue, or q <return> to quit---
        prim = 5311
        start = 0
        length = <value optimized out>
        i = 1
        tnl = (TNLcontext *) 0x8b25b08
        VB = (struct vertex_buffer *) 0x8b25f48
        tab = (tnl_render_func *) 0xb6c589a0
        pass = 0
        __PRETTY_FUNCTION__ = "run_render"
#5 0xb6b3c9db in _tnl_run_pipeline (ctx=0x8ad5eb0) at tnl/t_pipeline.c:158
        tnl = (TNLcontext *) 0x8b25b08
        __tmp = 895
        i = <value optimized out>
        mask = 63
#6 0xb6b3ceb3 in _tnl_draw_prims (ctx=0x8ad5eb0, arrays=0x8b13f30,
    prim=0x8b12a8c, nr_prims=1, ib=0x0, min_index=0, max_index=31)
    at tnl/t_draw.c:403
        bo = {0x1, 0x80b6f7b, 0x0, 0x0, 0x1, 0xbfe766a4, 0x8af4740, 0x8af4768,
  0xbfe76628, 0xb6b2a244, 0x8af47b0, 0xb6c58920, 0x40, 0xb7f07668, 0x80b6e2c,
  0x8b12968, 0xbfe76648, 0xb6b2a026, 0x8af4520, 0x0, 0x0, 0x0, 0x1,
  0x84217bde, 0xbfe76688, 0xb6b2a7dd, 0x8ad5eb0, 0x8af4778, 0x8af4744,
  0x8af4748, 0x8af4750, 0x8af4754, 0x8af4758}
        nr_bo = 0
---Type <return> to continue, or q <return> to quit---
        tnl = (TNLcontext *) 0x8b25b08
#7 0xb6b360b6 in vbo_exec_vtx_flush (exec=0x8b12968)
    at vbo/vbo_exec_draw.c:215
        ctx = (GLcontext *) 0x8ad5eb0
#8 0xb6b31ec8 in vbo_exec_wrap_buffers (exec=0x8b12968)
    at vbo/vbo_exec_api.c:80
        last_count = 32
        __PRETTY_FUNCTION__ = "vbo_exec_wrap_buffers"
#9 0xb6b31fed in vbo_exec_fixup_vertex (ctx=<value optimized out>, attr=3,
    sz=5311) at vbo/vbo_exec_api.c:218
        exec = (struct vbo_exec_context *) 0x8b12968
        i = <value optimized out>
        id = {0, 0, 0, 1}
#10 ...

Read more...

Revision history for this message
In , Brian-paul (brian-paul) wrote :

Created an attachment (id=11723)
patch for radeon_swtcl.c

Here's the same patch, but for the radeon driver.

Revision history for this message
In , Aurélien PROVIN (aprovin) wrote :

This patch works perfectly ! Blender doesn't crash.

I will use blender during one week to see if this patch is stable. But I think problem is solved. I will go back in one week to close or not this bug.

In any case, many thanks !

Revision history for this message
In , Brian-paul (brian-paul) wrote :

I think a change that I made to how _TriangleCaps is computed (last December) is the root cause here. I didn't realize _TriangleCaps was sometimes used before state validation (such as in ChooseRenderState()). So when I moved all the _TriangleCaps computation to state validation time it resulted in stale flags being used.

I'm working on a patch to undo that change (plus comments to document this mechanism).

Revision history for this message
In , Brian-paul (brian-paul) wrote :

Could you re-test with the latest code from git?

Otherwise, look for a 7.0.2 release candidate in the next day or two.

Revision history for this message
In , Alberto Luaces (azdo-b) wrote :

I'm the one who sent the second stack trace, I'm also using the radeon driver and applied the patch you sent, but Blender is still crashing when handling big meshes. After the crash, the stack is: (should I file another bug report for this one? It worked well with 6.5.1 and 6.5.2, the crashes started from 6.5.3)

#0 0xb73a201a in vbo_split_inplace (ctx=0x8e45df8, arrays=0xbfe982bc, prim=0xbf69b298, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb7302861 <_tnl_draw_prims>, limits=0xbf69b138) at vbo/vbo_split_inplace.c:271
271 memset(&split, 0, sizeof(split));
(gdb) bt
#0 0xb73a201a in vbo_split_inplace (ctx=0x8e45df8, arrays=0xbfe982bc, prim=0xbf69b298, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb7302861 <_tnl_draw_prims>, limits=0xbf69b138) at vbo/vbo_split_inplace.c:271
#1 0xb73a124c in vbo_split_prims (ctx=0x8e45df8, arrays=0xbfe982bc, prim=0xbf69b298, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb7302861 <_tnl_draw_prims>, limits=0xbf69b138) at vbo/vbo_split.c:152
#2 0xb7302932 in _tnl_draw_prims (ctx=0x8e45df8, arrays=0xbfe982bc, prim=0xbf69b298, nr_prims=15, ib=0x0, min_index=0, max_index=910)
    at tnl/t_draw.c:384
#3 0xb73a1fa3 in flush_vertex (split=0xbf69b274) at vbo/vbo_split_inplace.c:99
#4 0xb73a2449 in vbo_split_inplace (ctx=0x8e45df8, arrays=0xbfe982bc, prim=0xbf69b688, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb7302861 <_tnl_draw_prims>, limits=0xbf69b528) at vbo/vbo_split_inplace.c:255

... large call stack, maybe a stack overflow.

Revision history for this message
In , Brian-paul (brian-paul) wrote :

With gdb, can you print the value of ctx->Const.MaxArrayLockSize?

Revision history for this message
In , Alberto Luaces (azdo-b) wrote :

Yes:

Program terminated with signal 11, Segmentation fault.
#0 0xb73a201a in vbo_split_inplace (ctx=0x8e45df8, arrays=0xbfe982bc, prim=0xbf69b298, nr_prims=15, ib=0x0, min_index=0, max_index=910,
    draw=0xb7302861 <_tnl_draw_prims>, limits=0xbf69b138) at vbo/vbo_split_inplace.c:271
271 memset(&split, 0, sizeof(split));
(gdb) print ctx
$1 = (GLcontext *) 0x8e45df8
(gdb) print ctx->Const.MaxArrayLockSize
$2 = 910

Revision history for this message
In , Brian-paul (brian-paul) wrote :

Created an attachment (id=11816)
patch to fix VBO split infinite loop

Can you try this one-line patch to src/mesa/tnl/t_draw.c ?

Revision history for this message
In , Alberto Luaces (azdo-b) wrote :

I tried the example that was crashing and a few high density meshes more and I think it is fixed! Thank you very much!

Revision history for this message
In , Brian-paul (brian-paul) wrote :

I've commited the fix to git. Closing this bug report.

Revision history for this message
In , Sroland-vmware (sroland-vmware) wrote :

*** Bug 12968 has been marked as a duplicate of this bug. ***

Revision history for this message
In , lennyhome (lenny-mondogrigio) wrote :

*** Bug 12968 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Aurélien PROVIN (aprovin) wrote :

Bad news ... The bug is still present in 7.0.2 release :

(gdb) bt full
#0 triangle_twoside (ctx=0x8ad5e70, e0=1, e1=2, e2=0)
    at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:202
        vbcolor = <value optimized out>
        rmesa = (radeonContextPtr) 0x8acce88
        coloroffset = 3
        specoffset = 0
#1 0xb6b4fc9e in _tnl_render_poly_verts (ctx=0x8ad5e70, start=0, count=32,
    flags=57) at tnl/t_vb_rendertmp.h:313
        efstart = <value optimized out>
        efcount = <value optimized out>
        j = 3
        tnl = (TNLcontext *) 0x8b25ac8
        TriangleFunc = (const tnl_triangle_func) 0xb6ab1f70 <triangle_twoside>
        stipple = 0 '\0'
#2 0xb6b50e26 in run_render (ctx=0x8ad5e70, stage=0x8b25cdc)
    at tnl/t_vb_render.c:320
        prim = 3
        start = 0
        length = <value optimized out>
        i = 0
        tnl = (TNLcontext *) 0x8b25ac8
        tab = (tnl_render_func *) 0xb6c73ac0
        pass = 0
---Type <return> to continue, or q <return> to quit---
        __PRETTY_FUNCTION__ = "run_render"
#3 0xb6b482c3 in _tnl_run_pipeline (ctx=0x8ad5e70) at tnl/t_pipeline.c:158
        tnl = (TNLcontext *) 0x8b25ac8
        __tmp = 895
        i = 8
        mask = 63
#4 0xb6a9dbc2 in radeonWrapRunPipeline (ctx=0x8ad5e70) at radeon_state.c:2353
No locals.
#5 0xb6b48841 in _tnl_draw_prims (ctx=0x8ad5e70, arrays=0x8b13ef0,
    prim=0x8b12a4c, nr_prims=1, ib=0x0, min_index=0, max_index=31)
    at tnl/t_draw.c:402
        bo = {0x80b6e32, 0x80b6e30, 0x8b13d48, 0x0, 0x1, 0x403, 0x0,
  0xb7576a98, 0x80b6e2c, 0xb6bed9e1, 0x807bb24, 0x1, 0xb7f32ff4, 0x8b15ad8,
  0xbfe7be28, 0xbfe7be44, 0x0, 0x807bb24, 0xbfe7be28, 0xb7f337c4, 0x17, 0x0,
  0x1, 0x0, 0x1, 0xb6c722cc, 0x8ad5e70, 0x8b121e8, 0xbfe7bdf8, 0xb6af689b,
  0x8af4770, 0xb6c73a40, 0x40}
        nr_bo = 0
        tnl = (TNLcontext *) 0x8b25ac8
#6 0xb6b41430 in vbo_exec_vtx_flush (exec=0x8b12928)
    at vbo/vbo_exec_draw.c:215
        ctx = (GLcontext *) 0x8ad5e70
#7 0xb6b3cf48 in vbo_exec_wrap_buffers (exec=0x8b12928)
    at vbo/vbo_exec_api.c:80
---Type <return> to continue, or q <return> to quit---
        last_count = 32
        __PRETTY_FUNCTION__ = "vbo_exec_wrap_buffers"
#8 0xb6b3d096 in vbo_exec_fixup_vertex (ctx=<value optimized out>, attr=3,
    sz=4) at vbo/vbo_exec_api.c:218
        exec = (struct vbo_exec_context *) 0x8b12928
        i = <value optimized out>
        id = {0, 0, 0, 1}
#9 0xb6b40002 in vbo_Color4f (x=0, y=0, z=0, w=0.882353008)
    at vbo/vbo_attrib_tmp.h:163
No locals.
#10 0xb6bcb333 in loopback_Color4ub_f (red=<value optimized out>,
    green=<value optimized out>, blue=0 '\0', alpha=<value optimized out>)
    at main/api_loopback.c:228
No locals.
#11 0x08139c04 in BIF_ThemeColorShadeAlpha ()
No symbol table info available.
#12 0x08178efd in ?? ()
No symbol table info available.
#13 0x00000021 in ?? ()
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.

Revision history for this message
In , Sean Estabrooks (seanlkml) wrote :

Seeing essentially the same bug here as well on an i386 with 7.0.2:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208973616 (LWP 28389)]
triangle_twoside (ctx=0x9b2ced8, e0=1, e1=2, e2=0) at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:202
202 GLfloat (*vbcolor)[4] = VB->ColorPtr[1]->data;
(gdb) bt full
#0 triangle_twoside (ctx=0x9b2ced8, e0=1, e1=2, e2=0) at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:202
        vbcolor = <value optimized out>
        VB = (struct vertex_buffer *) 0x9b72088
        coloroffset = 3
        specoffset = 0 '\0'
#1 0x002c22d0 in _tnl_render_poly_verts (ctx=0x9b2ced8, start=0, count=32, flags=57)
    at tnl/t_vb_rendertmp.h:313
        efstart = <value optimized out>
        efcount = <value optimized out>
        j = <value optimized out>
        tnl = (TNLcontext *) 0x9b71c48
        VB = <value optimized out>
        TriangleFunc = (const tnl_triangle_func) 0x230550 <triangle_twoside>
        stipple = 0 '\0'
#2 0x002c3412 in run_render (ctx=0x9b2ced8, stage=0x9b71e8c) at tnl/t_vb_render.c:320
        prim = 2983563328
        start = 0
        length = <value optimized out>
        i = 0
        tnl = (TNLcontext *) 0x9b71c48
        VB = (struct vertex_buffer *) 0x9b72088
        tab = (tnl_render_func *) 0x417420
        pass = 0
        __PRETTY_FUNCTION__ = "run_render"
#3 0x002ba4ef in _tnl_run_pipeline (ctx=0x9b2ced8) at tnl/t_pipeline.c:158
        tnl = (TNLcontext *) 0x9b71c48
        __tmp = 895
        i = 10
        mask = 63
#4 0x0022a1d7 in intelRunPipeline (ctx=0x9b2ced8) at intel_tris.c:764
No locals.
#5 0x002baa4e in _tnl_draw_prims (ctx=0x9b2ced8, arrays=0x9b60078, prim=0x9b5ebd4, nr_prims=1, ib=0x0,
    min_index=0, max_index=31) at tnl/t_draw.c:402
        bo = {0x0 <repeats 13 times>, 0x366bf1, 0x0 <repeats 11 times>, 0x26b8ab, 0x9b4d2f0, 0x4173a0, 0x40,
  0x0, 0x0, 0x416f38, 0xbfb782b8}
        nr_bo = 0
        tnl = (TNLcontext *) 0x9b71c48
#6 0x002b307c in vbo_exec_vtx_flush (exec=0x9b5eab0) at vbo/vbo_exec_draw.c:215
        ctx = (GLcontext *) 0x9b2ced8
#7 0x002ae808 in vbo_exec_wrap_buffers (exec=0x9b5eab0) at vbo/vbo_exec_api.c:80
        last_count = 32
        __PRETTY_FUNCTION__ = "vbo_exec_wrap_buffers"
#8 0x002ae95c in vbo_exec_fixup_vertex (ctx=<value optimized out>, attr=3, sz=2983563328)
    at vbo/vbo_exec_api.c:218
        exec = (struct vbo_exec_context *) 0x9b5eab0
        i = <value optimized out>
        id = {0, 0, 0, 1}
#9 0x002b1c38 in vbo_Color4f (x=0, y=0, z=0, w=0.882353008) at vbo/vbo_attrib_tmp.h:163
        exec = (struct vbo_exec_context *) 0x9b5eab0
#10 0x00343cf3 in loopback_Color4ub_f (red=0 '\0', green=0 '\0', blue=0 '\0', alpha=225 '�')
    at main/api_loopback.c:228
No locals.
#11 0x081b77a4 in BIF_ThemeColorShadeAlpha ()

Revision history for this message
cellstije (marco-grimaldi) wrote : radeon dri and blender in gutsy
Download full text (3.2 KiB)

hi,

I am having issues with blender 2.44 (gutsy) using the radeon dri drivers.

The card is a sapphire radeon 9250 with 128MB.
lspci reports the following:
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)

Blender shows often (but not always) rendering errors while modelling.
Moreover if i switch to camera (0/ins key on the numeric pad) the center of the view is black.
Finally it tends to crash if i try to move away form camera mode (hitting key 7 or key 3 on the numeric pad).
The crash is reproduceable easily.
Below the output of gdb:

(gdb) file /usr/bin/blender-bin
Reading symbols from /usr/bin/blender-bin...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/blender-bin
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1225237840 (LWP 7028)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Compiled with Python version 2.5.1.
Checking for installed Python... got it!
(no debugging symbols found)
(no debugging symbols found)
Ignoring Xlib error: error code 171 request code 147
Ignoring Xlib error: error code 171 request code 147
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225237840 (LWP 7028)]
0xb6c977c5 in ?? () from /usr/lib/dri/r200_dri.so
(gdb) bt
#0 0xb6c977c5 in ?? () from /usr/lib/dri/r200_dri.so
#1 0xffffffff in ?? ()
#2 0x00000001 in ?? ()
#3 0xbfa34058 in ?? ()
#4 0xb6c8e9a4 in r200UpdateTextureState () from /usr/lib/dri/r200_dri.so
#5 0xb6d28835 in ?? () from /usr/lib/dri/r200_dri.so
#6 0x08b12a88 in ?? ()
#7 0x00000001 in ?? ()
#8 0x00000002 in ?? ()
#9 0x00000000 in ?? ()
(gdb)

I found a similar problem reported way back:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug...

Read more...

Revision history for this message
cellstije (marco-grimaldi) wrote :

I forgot to mention that i disabled both composite extensions and aiglx in the xorg, just to avoid issues related to it

best

m.

Revision history for this message
Wrwrwr (wrwrwr) wrote :

I can confirm this one. This must be something about some new drivers, because blender used to work fine on this machine.

Hardware:
Card: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
Processor: AMD Athlon(tm) 64 Processor 2800+
Chipset: nVidia Corporation nForce3 250Gb
(There are some more similar reports in different places about all with radeons 9200 & 9250.)

Software:
Ubuntu 7.10, x64.
OpenGL renderer string: Mesa DRI R200 20060602 AGP 8x TCL
OpenGL version string: 1.3 Mesa 7.0.1
Blender 2.44 and 2.45 with Python 2.5.1.

A discussion on freedesktop.org pointing which mesa versions work and which don't:
http://<email address hidden>/msg32485.html
(You can find a patch there, but only solving the crash not the black square, not really helpful.)

Attaching a screenshot and a backtrace.

Revision history for this message
Wrwrwr (wrwrwr) wrote :
Revision history for this message
In , Isak-sr (isak-sr) wrote :

I confirm bug is still present on 7.0.2. Im using Fedora 8, BLENDER 2.45 with intel 945GM. There are more users with this card and similar with the same problem. We compiled 7.0.2 from source and didnt work us. We posted the bug on the redhat bugzilla.

Revision history for this message
In , Shuang-he (shuang-he) wrote :

Hi, Isaac Salgado
Pls open a new bug report for this issue on 945gm, So we can track this better(In reply to comment #24)
> I confirm bug is still present on 7.0.2. Im using Fedora 8, BLENDER 2.45 with
> intel 945GM. There are more users with this card and similar with the same
> problem. We compiled 7.0.2 from source and didnt work us. We posted the bug on
> the redhat bugzilla.
>

Hi, Isaac Salgado
Pls open a new bug report for this issue on 945gm, So we can track this better

Revision history for this message
In , Brian-paul (brian-paul) wrote :

Can you possibly try the latest code from Mesa git on the mesa_7_0_branch branch? I fixed a two-sided lighting bug a couple weeks ago that might solve this.

Revision history for this message
In , Aurélien PROVIN (aprovin) wrote :

Please do not change the original bug report. If the bug is present in another driver, please indicate in a new message.

I will test the latest code from Mesa git asap.

Revision history for this message
In , Brice Goglin (brice-goglin) wrote :

According to Dietrich Bollmann, the crash is fixed with latest mesa 7.0.x branch (he's using Debian Mesa 7.0.2-3 which contains the branch up to commit 0107acde).

Revision history for this message
Wrwrwr (wrwrwr) wrote : Re: radeon dri and blender in gutsy

There is now Blender with statically compiled MesaGL available for download from the official site (64-bit version). It works fine for me, with no crashes at all.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Can you please install libgl1-mesa-dri-dbg and try to get a new backtrace?

Changed in xserver-xorg-video-ati:
assignee: nobody → tormodvolden
status: New → Incomplete
Revision history for this message
In , Oxben (oxben) wrote :

I confirm the bug seems to be fixed in mesa_7_0_branch (checked out 4th january).

I had exactly the same crash as Sean in comment #23 (same stack trace) on a fresh Fedora 8 installation with an intel i865 chipset (DRI "driver" i915_dri.so).

I recompiled the latest sources from mesa_7_0_branch, and Blender started like a charm. :)

Revision history for this message
cellstije (marco-grimaldi) wrote : Re: [Bug 174479] Re: [r200] radeon dri and blender in gutsy

I installed the package libgl1-mesa-dri-dbg but the backtrace is the same:

This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/blender-bin
(no debugging symbols found)
(no debugging symbols found)
[...]
(no debugging symbols found)
Ignoring Xlib error: error code 171 request code 147
Ignoring Xlib error: error code 171 request code 147
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225250128 (LWP 7214)]
0xb6c947c5 in ?? () from /usr/lib/dri/r200_dri.so
(gdb) backtrace full
#0 0xb6c947c5 in ?? () from /usr/lib/dri/r200_dri.so
No symbol table info available.
#1 0xffffffff in ?? ()
No symbol table info available.
#2 0x00000001 in ?? ()
No symbol table info available.
#3 0xbf9df7a8 in ?? ()
No symbol table info available.
#4 0xb6c8b9a4 in r200UpdateTextureState () from /usr/lib/dri/r200_dri.so
No symbol table info available.
#5 0xb6d25835 in ?? () from /usr/lib/dri/r200_dri.so
No symbol table info available.
#6 0x08b0dbc8 in ?? ()
No symbol table info available.
#7 0x00000001 in ?? ()
No symbol table info available.
#8 0x00000002 in ?? ()
No symbol table info available.
#9 0x00000000 in ?? ()
No symbol table info available.
(gdb) bt
#0 0xb6c947c5 in ?? () from /usr/lib/dri/r200_dri.so
#1 0xffffffff in ?? ()
#2 0x00000001 in ?? ()
#3 0xbf9df7a8 in ?? ()
#4 0xb6c8b9a4 in r200UpdateTextureState () from /usr/lib/dri/r200_dri.so
#5 0xb6d25835 in ?? () from /usr/lib/dri/r200_dri.so
#6 0x08b0dbc8 in ?? ()
#7 0x00000001 in ?? ()
#8 0x00000002 in ?? ()
#9 0x00000000 in ?? ()

Best
m.

On 1/3/08, Tormod Volden <email address hidden> wrote:
> Can you please install libgl1-mesa-dri-dbg and try to get a new
> backtrace?
>
> ** Summary changed:
>
> - radeon dri and blender in gutsy
> + [r200] radeon dri and blender in gutsy
>
> ** Changed in: mesa (Ubuntu)
> Sourcepackagename: xserver-xorg-video-ati => mesa
> Assignee: (unassigned) => Tormod Volden (tormodvolden)
> Status: New => Incomplete
>
> --
> [r200] radeon dri and blender in gutsy
> https://bugs.launchpad.net/bugs/174479
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Ouch, that was 189 MB for nothing then :) Well, it can still prove useful.

From looking closer at the backtrace, we can see that the stack is clearly messed up, since it has addresses like 0x00000001 and 0xffffffff. If this crash is reproducible, it should be possible to define a breakpoint (for instance on r200UpdateTextureState?) and enable it just before making it crash. From there on, see how far you can get with stepping or refining breakpoints until you get a backtrace while it still uncorrupted. I admit this can be quite an exercise in gdb... A good introduction is on http://www-128.ibm.com/developerworks/library/l-gdb/

Revision history for this message
Tormod Volden (tormodvolden) wrote :

If this is the same issue as in the upstream bug, it should be fixed in Hardy by now (mesa 7.0.2-3ubuntu1). Please test, for instance with the alpha 3 release due this week.

Changed in mesa:
status: Unknown → Confirmed
Revision history for this message
cellstije (marco-grimaldi) wrote :

Tormod,

I saw you have a PPA (https://launchpad.net/~tormodvolden/+archive)
I may check installing your packages on gutsy, if you think it would be useful.

I have a spare machine which I use for websurfing, email I can use.

Best

m.

On 1/10/08, Bug Watch Updater <email address hidden> wrote:
> ** Changed in: mesa
> Status: Unknown => Confirmed
>
> --
> [r200] radeon dri and blender in gutsy
> https://bugs.launchpad.net/bugs/174479
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Yes, you can get the latest -ati driver from my ppa, but my mesa packages are not up to date. It would be nice if you could test alpha 3 for instance by running the live CD.

Revision history for this message
cellstije (marco-grimaldi) wrote :

ok, i'll check the live cd when i have a bit of time

m.

On 1/15/08, Tormod Volden <email address hidden> wrote:
> Yes, you can get the latest -ati driver from my ppa, but my mesa
> packages are not up to date. It would be nice if you could test alpha 3
> for instance by running the live CD.
>
> --
> [r200] radeon dri and blender in gutsy
> https://bugs.launchpad.net/bugs/174479
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
cellstije (marco-grimaldi) wrote :

Just checked with the Hardy Alpha 3 and the bug is not present anymore!

best
m.

On Jan 16, 2008 9:14 AM, Marco Grimaldi <email address hidden> wrote:

> ok, i'll check the live cd when i have a bit of time
>
> m.
>
> On 1/15/08, Tormod Volden <email address hidden> wrote:
> > Yes, you can get the latest -ati driver from my ppa, but my mesa
> > packages are not up to date. It would be nice if you could test alpha 3
> > for instance by running the live CD.
> >
> > --
> > [r200] radeon dri and blender in gutsy
> > https://bugs.launchpad.net/bugs/174479
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Thanks for testing, cellstije.

Changed in mesa:
assignee: tormodvolden → nobody
status: Incomplete → Fix Committed
Revision history for this message
In , Hiben (hiben) wrote :

I would also like to confirm that I had very similar issues (with blender 2.45 and also gltron (HP ZE4500, x86, Gentoo)) with a IGP320M in 7.0.2 and that they are gone using the sources from git.

Changed in mesa:
status: Fix Committed → Fix Released
Revision history for this message
abp (andres-peratta) wrote :

Hi, I run opensuse 10.3 and have similar problems with blender and /usr/lib/dri/r200_dri.so

Mesa-7.0.1
ATI Mobility radeon 9200,
My Xorg.conf file contains the following lines in the "Device" section:
  BoardName "RV280 5c61"
  Driver "radeon"
  Identifier "Device[0]"
  VendorName "ATI"

Both Blender 2.44 and Blender 2.45 give me segmentation fault after a few minutes of use.
With gdb blender I get the below outcome. Any idea how to solve it? Should I try to install Mesa 7.0.2 ?
,
abp

/home/andres/blender-2.45-linux-glibc236-py25-i386> gdb blender
GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /home/andres/utils/blender-2.45-linux-glibc236-py25-i386/blender
(no debugging symbols found)
...
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb77aa6d0 (LWP 5873)]
(no debugging symbols found)
...
(no debugging symbols found)
Compiled with Python version 2.5.1.
Checking for installed Python... got it!
(no debugging symbols found)
...
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77aa6d0 (LWP 5873)]
0xb76a415d in ?? () from /usr/lib/dri/r200_dri.so
(gdb) bt
#0 0xb76a415d in ?? () from /usr/lib/dri/r200_dri.so
#1 0x00000004 in ?? ()
#2 0x3fff4b4c in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000003 in ?? ()
#5 0x00000002 in ?? ()
#6 0x00000000 in ?? ()

Revision history for this message
Tormod Volden (tormodvolden) wrote :

abp, yes try a newer mesa. 7.0.2 is not enough, you'll need something updated, like 7.0.2-3 in Debian. But I don't know what you have available in opensuse.

Revision history for this message
abp (andres-peratta) wrote :

Thank you very much for your great support!!
I found that mesa-7.0.3 is available as RPM for opensuse 10.3 from:

http://download.opensuse.org/repositories/home:/zwabel/openSUSE_10.3/i586/

or searching for mesa in: http://software.opensuse.org/search

After installing it, all the problems with blender solved.
Thank you once again.
All best,
abp

Bryce Harrington (bryce)
Changed in xserver-xorg-video-ati:
status: New → Fix Released
Revision history for this message
In , Timo Jyrinki (timo-jyrinki-hut) wrote :

Reported to be fixed in the last comments.

Changed in mesa:
status: Confirmed → Fix Released
Changed in mesa:
importance: Unknown → Medium
Changed in mesa:
importance: Medium → Unknown
Changed in mesa:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.