3D corruption with free ati driver

[Alberto Luaces]

I see display corruption when running 3D applications like Blender. It seems the free ati/radeon driver has problems with applications that use several viewports and can't clear the buffers correctly. I noticed this behavior after upgrading to 7.04 from 6.10. I will post images of Blender and a program of mine in the next message.

My card is a ATI mobility radeon 7500 on a ThinkPad R51.

[Alberto Luaces (azdo-b)]

This is a screenshot of Blender 2.43. Also happens with previous versions of Blender (like 2.42), so I think is a problem of the driver.

[Alberto Luaces (azdo-b)]

This is program of mine where it is shown that the buffer clearing of the small view is not working. The bottom blue area is what is being cleared instead. This program works fine on previous versions of Ubuntu other Windows versions.

[Alberto Luaces (azdo-b)]

I forgot to add two warning messages that get written to console when running Blender:

Ignoring Xlib error: error code 169 request code 145
Ignoring Xlib error: error code 169 request code 145

[Alberto Luaces (azdo-b)]

Added xorg.conf

[Emanuele Gissi (emanuele-gissi)]

My card: Ati radeon 9250 with free ati driver.
I confirm the font corruption!
Ready to send what you need to correct the bug.
Emanuele.

[Timo Jyrinki (timo-jyrinki)]

I had one font corruption too, with Radeon Mobility 9000. So it seems there was a bug in Mesa 6.5.2 (which is a development version, after all...). I installed the new Mesa 6.5.3 from http://mesa3d.org/ which seemed to fix that problem and probably many others, too.

You can test if the new Mesa fixes the problems for you by downloading the 6.5.3 sources, running make linux-dri-x86 (or make linux-dri-x86-64) and then before starting the application from a terminal type export LIBGL_DRIVERS_PATH=/your_path_to_mes/Mesa-6.5.3/lib/ (or lib64 if using amd64 computer). You can check that it works by running glxinfo that should tell you about the version 6.5.3.

[Alberto Luaces (azdo-b)]

Thank you very much, Timo. I can also confirm that the problem goes away in Blender and my custom applications (the video corruption is finally gone!) after using Mesa 6.5.3, following your instructions. I had, however, to remove in the last line of config/linux-dri the "nouveau" word, as this prevented the compilation to finish succesfully. When compiling the nouveau driver, an error is issued when the compiler does not find the file nouveau_drm.h, not present on the 6.5.3 sources.

I'm changing the package "xserver-xorg-video-ati (Ubuntu)" to "Mesa".

[Alberto Luaces (azdo-b)]

I tested a little the 6.5.3 version. It crashes blender 2.43 and 2.41 when changing from edit mode to object mode. Reverting the mesa drivers to 6.5.1, found on edgy, hasn't that problem and blender works correctly.

[Alberto Luaces (azdo-b)]

The new Mesa version found on Gutsy seems to work well. To use it, I had to upgrade the following packages:

libc6_2.6.1~pre-0ubuntu1_i386.deb
libgl1-mesa-dri_7.0.0-0ubuntu2_i386.deb
libgl1-mesa-glx_7.0.0-0ubuntu2_i386.deb
libxdamage1_1.1.1-3_i386.deb

[Alberto Luaces (azdo-b)]

Sorry, I forgot to test 6.5.3 against Blender. It keeps crashing when editing meshes, so Blender is still unusable even the graphic corruption bug is gone.

[Aurélien PROVIN (aprovin)]

I have an ATI radeon IGP 320M (mobility U1) card which works well with
radeon driver. 2d and 3d accelerations are working. But there is a problem
with Blender with DRI driver 7.0.1

My version of blender is 2.44.

guessing 'blender-bin' == '/usr/bin/blender-bin'
Compiled with Python version 2.4.4.
Checking for installed Python... got it!
/usr/bin/blender: line 46: 12850 Segmentation fault blender-bin "$@"

I installed libgl1-mesa-dri-dbg and libgl1-mesa-glx-dbg packages due to debug with gdb :

#0 triangle_twoside (ctx=0x929c0a0, e0=1, e1=2, e2=0)
    at ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:202
#1 0xb74cdcf5 in _tnl_render_poly_verts (ctx=0x929c0a0, start=0, count=32,
    flags=57) at tnl/t_vb_rendertmp.h:313
#2 0xb74ced52 in run_render (ctx=0x929c0a0, stage=0x92f07dc)
    at tnl/t_vb_render.c:320
#3 0xb74c652b in _tnl_run_pipeline (ctx=0x929c0a0) at tnl/t_pipeline.c:158
#4 0xb74c6a03 in _tnl_draw_prims (ctx=0x929c0a0, arrays=0x92dea00,
    prim=0x92dd55c, nr_prims=1, ib=0x0, min_index=0, max_index=31)
    at tnl/t_draw.c:403
#5 0xb74bfc06 in vbo_exec_vtx_flush (exec=0x92dd438)
    at vbo/vbo_exec_draw.c:215
#6 0xb74bba18 in vbo_exec_wrap_buffers (exec=0x92dd438)
    at vbo/vbo_exec_api.c:80
#7 0xb74bbb3d in vbo_exec_fixup_vertex (ctx=<value optimized out>, attr=3,
    sz=3031035952) at vbo/vbo_exec_api.c:218
#8 0xb74be9e4 in vbo_Color4f (x=0, y=0, z=0, w=0.882353008)
    at vbo/vbo_attrib_tmp.h:163
#9 0x081f9420 in BIF_ThemeColorShadeAlpha ()
#10 0x082d5fa4 in draw_object ()
#11 0x08199357 in drawview3dspace ()
#12 0x081bf90d in scrarea_do_windraw ()
#13 0x081c9339 in screenmain ()
---Type <return> to continue, or q <return> to quit---
#14 0x0818df16 in main ()

[Aurélien PROVIN (aprovin)]

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

[Alberto Luaces (azdo-b)]

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

[Brian-paul (brian-paul)]

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.

[Alberto Luaces (azdo-b)]

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

[Aurélien PROVIN (aprovin)]

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

[Brian-paul (brian-paul)]

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.

[Aurélien PROVIN (aprovin)]

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

[Brian-paul (brian-paul)]

Created an attachment (id=11693)
r200ChooseRenderState patch

Here's another patch to try.

[Aurélien PROVIN (aprovin)]

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

[Brian-paul (brian-paul)]

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

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

[Aurélien PROVIN (aprovin)]

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 !

[Brian-paul (brian-paul)]

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

[Brian-paul (brian-paul)]

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.

[Alberto Luaces (azdo-b)]

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.

[Brian-paul (brian-paul)]

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

[Alberto Luaces (azdo-b)]

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

[Brian-paul (brian-paul)]

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 ?

[Alberto Luaces (azdo-b)]

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

[Brian-paul (brian-paul)]

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

[Tormod Volden (tormodvolden)]

(closing -ati task since this seems to be a mesa problem)

[Alberto Luaces (azdo-b)]

FYI, it is now solved on Mesa git.

[Tormod Volden (tormodvolden)]

Do you know which commit solved it?

[Alberto Luaces (azdo-b)]

I don't know the revision number, but the commit took place on 2007-09-29. The bug report number is 12164.

[Tormod Volden (tormodvolden)]

Thanks, that must be git commit f8ee72d98f2d23e034e90870ff6a760659a462a5 "fix VBO-split infinite loop (bug 12164)"

[Tormod Volden (tormodvolden)]

I uploaded a new version of mesa with this fix to my PPA. Please try the mesa packages from https://edge.launchpad.net/%7Etormodvolden/+archive

[Tormod Volden (tormodvolden)]

The patch is a one-liner (one character) and fixes a logical mistake (typo?) from => to >.

[Alberto Luaces (azdo-b)]

Sorry, I'm not using Ubuntu any more, so I can't test the package, but you are correct, the patch was the one you pointed about exchanging '>' with '>='.

[Sroland-vmware (sroland-vmware)]

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

[lennyhome (lenny-mondogrigio)]

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

[Aurélien PROVIN (aprovin)]

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.

[Sean Estabrooks (seanlkml)]

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 ()

[Vadim Peretokin (vperetokin)]

I'm using Ubuntu 7.10, Radeon 7500 (on a ThinkPad T40), and the "radeon" driver in my xorg.conf.

Since upgrading to Gutsy from Fiesty, I'm have a whole lot of problems - but I'm not sure what are they related to.

The problems are that certain graphical apps completely freeze up my laptop now, while they were fine in 7.04. For example, neverball completely locks my laptop up (I can only move the mouse, but the system is completely unresponsive. I have to hard reboot it), while it was fine in 7.04. Along with Thunder&Lightning.

Also while the Blender screen was really weird on Fiesty, when I tried it now, it completely locked my laptop up too - similarly to neverball and tnl. But thankfully this time it unfroze after 5 mins or so (bad me was testing with important apps open and data not saved).

Glxinfo reports the following:

OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20061018 AGP 4x x86/MMX/SSE2 TCL
OpenGL version string: 1.3 Mesa 7.0.1

Is there anything else that I can provide? This is really annoying.

[Tormod Volden (tormodvolden)]

Vadim, please file a bug report.

[Tormod Volden (tormodvolden)]

The above mentioned commit is now released in the Hardy 7.0.2 version.

[Isak-sr (isak-sr)]

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.

[Shuang-he (shuang-he)]

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

[Brian-paul (brian-paul)]

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.

[Aurélien PROVIN (aprovin)]

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.

[Brice Goglin (brice-goglin)]

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

[Oxben (oxben)]

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

[Hiben (hiben)]

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.

[Timo Jyrinki (timo-jyrinki-hut)]

Reported to be fixed in the last comments.