Run any version of Blender, enter camera view with NUMPAD-0, then enter top view with NUMPAD-7. Blender will crash at this point. Here's what gdb says: ---- lenny@lenny:~/junk/blender-2.45-linux-glibc236-py25-i386$ LD_LIBRARY_PATH=/home/lenny/junk/Mesa-6.5.3/lib:$LD_LIBRARY_PATH LIBGL_DRIVERS_PATH=/home/lenny/junk/Mesa-6.5.3/lib gdb ./blender GNU gdb 6.6-debian Copyright (C) 2006 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 "i486-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run Starting program: /home/lenny/junk/blender-2.45-linux-glibc236-py25-i386/blender (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) [Thread debugging using libthread_db enabled] [New Thread -1217431872 (LWP 23328)] Compiled with Python version 2.5.1. Checking for installed Python... got it! libGL warning: 3D driver claims to not support visual 0x60 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1217431872 (LWP 23328)] 0xb741fbb1 in triangle_twoside (ctx=0x919bde0, 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) quit The program is running. Exit anyway? (y or n) y lenny@lenny:~/junk/blender-2.45-linux-glibc236-py25-i386$ ---- You'll notice that some 2D primitives don't get drawn correctly, especially horizontal lines. I've recompiled and tested some other versions of MesaLib and 6.4.2 works perfectly fine. Any later version (including 7.0.1) has the problem I've described above. The first time I've noticed this problem was when I upgraded form Ubuntu 6.06 to Ubuntu 7.02. Blender is unusable since then on linux with radeon hardware.
Looks like #12164 to me. Should be already fixed in git master and git mesa_7_0_branch. *** This bug has been marked as a duplicate of bug 12164 ***
Thank you for your reply, but this bug is not resolved. I checked out the sources from GIT two days ago and I noticed that it only got worse. Unless you fixed this issue yesterday or so, Mesa GIT's version freezes the whole machine. I'm sorry I can't give you a gdb output from that because my machine becomes unresponsive just before I leave the camera view in blender as I described in this bug report. To recap, on radeon hardware, Mesa-6.4.2 works. Any later version crashes on some 2D prims that blender uses when drawing the camera's passepartout. Pleas contact me if you have questions or need me to try something in particular.
(In reply to comment #2) > Thank you for your reply, but this bug is not resolved. I checked out the > sources from GIT two days ago and I noticed that it only got worse. Unless you > fixed this issue yesterday or so, Mesa GIT's version freezes the whole machine. If you've trouble with git master, try the mesa_7_0_branch. > I'm sorry I can't give you a gdb output from that because my machine becomes > unresponsive just before I leave the camera view in blender as I described in > this bug report. Hmm ok. If you have attached gdb locally and it gets unresponsive upon a crash this usually means it crashed when the hw lock was held. I don't think the driver should have the lock where it used to crash, so it might be a different issue now. The most easy way to get a backtrace would be to use a remote machine for gdb.
I can launch blender like this: LD_LIBRARY_PATH=/home/lenny/junk/Mesa-6.4.2/lib:$LD_LIBRARY_PATH LIBGL_DRIVERS_PATH=/home/lenny/junk/Mesa-6.4.2/lib ./blender Problem solved... I mean... no need to bother with GIT branches :) Anyway I just checked out the GIT again and read the bug you thought this one was a duplicate of. To me it looks like you fixed a problem very similar to the one I'm reporting (an infinite loop and something else) in the r200 driver recently but the radeon driver has remained unchanged. Other than this I don't know. I don't have time to set up a remote gdb session and, as I just mentioned, I found a workaround. Thank you again for your attention.
(In reply to comment #4) > I can launch blender like this: > > LD_LIBRARY_PATH=/home/lenny/junk/Mesa-6.4.2/lib:$LD_LIBRARY_PATH > LIBGL_DRIVERS_PATH=/home/lenny/junk/Mesa-6.4.2/lib ./blender > > Problem solved... I mean... no need to bother with GIT branches :) Well - it's still a bug which needs to be fixed. > Anyway I just checked out the GIT again and read the bug you thought this one > was a duplicate of. To me it looks like you fixed a problem very similar to the > one I'm reporting (an infinite loop and something else) in the r200 driver > recently but the radeon driver has remained unchanged. I didn't fix it, Brian did... But the fix which got into git is not what the patch looks like, it should have fixed all drivers.
Created attachment 12291 [details] Part of Blender's interface drawn with Mesa 6.4.2 on a radeon card
Created attachment 12292 [details] Part of Blender's interface drawn with Mesa GIT on a radeon card
Besides the crashes/machine hangs I already reported, if you notice, on Mesa version > 6.4.2 (including 7.0.1 and current GIT version) half of the exactly horizontal and vertical lines are drawn incorrectly.
I did some other tests. I downloaded, compiled and tested all released Mesa version starting from 6.4.2 to try to find the exact version that caused this regression. The results are as follows: Mesa-6.4.2 -> Works. Accurate and stable. Water reflections in Sauerbraten are drawn incorrectly. Mesa-6.5 -> Works. Accurate and stable. Mesa-6.5.1 -> Works. Accurate and stable. Mesa-6.5.2 -> All lines and polygons are drawn correctly, but the z-buffer don't get cleared properly. Large chucks of blender's interface gets partially overdrawn over and over. Otherwise stable. Mesa-6.5.3 -> Broken as described in this bug report. Mesa-7.0 / Mesa-7.0.1 -> Broken as described in this bug report. Mesa GIT -> Broken as described in this bug report, plus instead of just crashing an application, it hangs the machine. For some reason it hangs much faster if I try to debug it with RADEON_DEBUG=dri for example. When it hangs, I can still move the mouse but I can't do anything else like switch to another VT or kill the X server.
I manually applied this patch: https://bugs.freedesktop.org/attachment.cgi?id=11723 and blender don't segfault anymore. Too bad it's still unusable because in camera view instead of a rounded square line surrounding the scene, I see a black, filled square that completely covers it. Half of the GL_LINE_LOOPs have the line that should close the loop missing. That patch definitely solves the crash thought, so I'm resolving this bug as a duplicate as suggested before, but please consider the other issues I've mentioned. Since you decided switch to VBO, mesa has been... to put it mildly... shaky. And it would be nice to have a really stable version, maybe delaying a bit other projects about shaders and the newest OpenGL API calls of which not everybody cares about. *** This bug has been marked as a duplicate of bug 12164 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.