I can confirm this crash with the 32bit version, the 64bit version however seems to work fine. Testing on OS X 10.7.5.

Jens, any idea what is going on here? This is the backtrace, some libstdc++ issue.

0 libstdc++.6.dylib 0x967b5c07 std::locale::operator=(std::locale const&) + 27
1 libstdc++.6.dylib 0x967b5880 std::ios_base::_M_init() + 58
2 libstdc++.6.dylib 0x967c24d7 std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) + 25
3 org.blenderfoundation.blender 0x007b1dd2 IMB_exrtile_begin_write + 642
4 org.blenderfoundation.blender 0x003a6d23 render_result_exr_file_begin + 195
5 org.blenderfoundation.blender 0x00395914 threaded_tile_processor + 1476
6 ??? 0x05ed3c20 0 + 99433504

K, found something:
The for 64bit needed additional libstdc.dylib is culprit in 32bit crash.
I removed the linkage and all is fine with render/full_sample again.
I hope i has no other sideeffects ( did not found any yet ).
I do i silent update for the i386 build, pls releoad when up and check.

Jens

Hi,

I've experienced too some problems when rendering with full samples activated with official build blender 2.64a. Blender freezes at some early frame during the render, but not right at the start. This using an i7 computer with 16 GB RAM, Nvidia Geforce 670 with 304.51 version of proprietary driver in a Debian Wheezy system.

Ran the render without problems in a Dell Core 2 Duo computer, with 4GB of RAM, an Nvidia Quadro 1600M and driver version 295.53, proprietary too and Debian Squeeze OS.

On the Squeeze system, libstdc is libstdc++6 version 4.4.5-8. On the Wheezy system, was libstdc++6 too version 4.6.3-8 but updated along with regular updates of the operating system (no forced update) after reading this, to 4.6.3-11 version. Problem still issuing after this update.

Running from terminal doesn't deliver particular info as it freezes too without any special message, in the middle of the read/write exr operations (for the full sample, I guess). By the way, rendering the exact same file with Blender 2.63a works normally without problems.

Recently I had some problems with graphic server on the Wheezy system and, after solving this, I no longer have the OpenCL option on the System preferences tab. Guessing that OpenCL isn't functional right now in my system; just in case this could be related to the issue.

Hope this is going to be helpful. Regards,
Raimon

By the way, both systems and builds are 64 bits.

Just before posting what follows this, noticed that the file .xsession-errors in my home directory grew up to 67 GB!!! I hardly can open this, but for what I've seen it's full of Gnome-shell and tracker related errors, along with the rendering verbose output of blender. So chances are that is an issue of mine related to gnome shell. I've already planned to reinstall my whole operating system, but I leave what follows just in case it could be useful to someone for further investigating:

<<<<<
Attached a couple of files related to the issue, into prova_bug.zip

I'm able to reproduce the bug in prova_bug.blend, but not in prova_bug_packed.blend which contains the original font issued embedded (Gentium).

Sorry for being a little messy with this followups but this issue seems to not obey at any kind of logic. Only trying to be helpful and reducing to the minimum the complexity as recommended in bug reporting guidelines. But is hard for me too to test when sometimes rendering fails at frame 12 and sometimes it fails at 85, and some other times don't fail at all.

Perhaps the issue could be related to the fact that Blender is taking the font from a non user directory (/usr/share/fonts) ???? Noted one more thing: now I'm able to write well tildes like è é ò ó and so which was not possible previously. Perhaps the issue has nothing to do with fonts, because I've tested too with a simple cube but I've not achieved a full reproductability of the bug. So, again, sorry for being a little messy.

I guess the key issues to reproduce the bug are:
- full sample activated. composite nodes activated. Dimensions 100%
- vector pass activated and vector blur node present, all properly connected between renderlayer and composite output
- viewer node present and backdrop monitor activated
- perhaps PAL settings (720x576) too, with modified pixel aspect ratio from 12x11 to 1x1
>>>>>>

Jens posted new builds, zef, could you pleas test it? Otherwise I suggest to close this.

@Raimon, is that related to the original report here?

I can't see a instant crash on Windows x64 with SVN 51318 with Full Samples enabled (rendering default scene)

On October 16 I tested with the latest build from Blender.org (blender-2.64a-release-OSX_10.6_i386.zip)
on the same os 10.6.8 machine which used to crash.

Rendering with full sample works fine now.

That's awesome, thanks!

Just found that if I render frames larger than 2160x2160 with Anti-Aliasing set to 16 and Full Sample enabled, the same crashing behavior returns, even tested on empty scenes.

2.64.0 r51232
OS 10.6.8
NVIDIA GeForce GT 120
2 x 2.26 GHz Quad-Core Intel Zeon
24 GB 1066 MHz DDR3

I couldn't redo the crash and didn't see memory usage go higher than 800 MB. Are you perhaps using only 1x1 tiles or so? The file is set to 8x8 but I'm not sure what else would be causing it.

However, you should use the 64bit (x86_64, not i386) Blender version if you have a system with 24 GB. Otherwise you can only use up to 4 GB of memory, and 64 bit Blender versions nowadays are better tested than 32bit.