Blender crashes everytime for me lately when editing materials. I've attached a simple blend example file. It's Suzanne with glass material added.
To crash Blender :
1. Edit Specular->Hardness (for example*) with (important!) your mouse.
2. Click on Hardness value, hold and move the mouse cursor to change the value.
3. Blender crashes evrytime for me.
* Well, it crashes when editing every other (I think, didn't try every single one) value with mouse cursor. When I just click the value and edit it manualy with a keyboard it is all OK. Maybe the crash is when the preview gets updated? I dunno.
I've tested this on a Macbook Pro and have attached the crash report.
Description
Description
Event Timeline
Comment Actions
Can't get this to crash on 64bit linux, from the crash log this looks like either a bug in blenders threading or a bug in icon drawing,
(which could be a driver specific bug or a problem in blenders OpenGL use which only breaks on some configurations).
Comment Actions
I've recorded 1 minute video from my screen:
http://www.youtube.com/watch?v=ZJQi-T9K6ZI
As you can see there, when I first open Blender 2.59 and edit the material everything's fine. I can change values, preview gets updated, everythings great. But in Blender 2.60 RC Blender crashes right after I edit the Hardness value. In a second attempt it crashes while editing the Emit value. It happens all the time in 2.60 and never did in 2.59.
Comment Actions
Hi
I recently found an issue in errorhandling that might be related.
Although cannot reproduce your crash here atm.
Could you pls test this build ? --> http://www.jensverwiebe.de/Blender/blender_gcclib_repair.zip
Jens
Comment Actions
Let me use a quote from Inglourious Basterds here: "That's a bingo!" :-) No more crashes with your version. Thanks, Jens!
Comment Actions
Oki, i close this bug now.
Explanation:
There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc.
Therefore, the G++ and GCJ drivers automatically add -shared-libgcc whenever you build a shared library or a main executable, because C++ and Java programs typically use exceptions, so this is the right thing to do.
If, instead, you use the GCC driver to create shared libraries, you may find that they will not always be linked with the shared libgcc. If GCC finds, at its configuration time, that you have a non-GNU linker or a GNU linker that does not support option --eh-frame-hdr, it will link the shared version of libgcc into shared libraries by default. Otherwise, it will take advantage of the linker and optimize away the linking with the shared version of libgcc, linking with the static version of libgcc by default. This allows exceptions to propagate through such shared libraries, without incurring relocation costs at library load time.
Solution: i will link next rc`S to shared liggcc and deliver it inside bundle.
Jens