linux official build glibc 219 crash
Closed, ResolvedPublic


System Information
Linux CentOS 7

Blender Version
Broken: 2.78a glibc 219, 2,78b, 2,78c
Worked: 2.78a glibc 211

Short description of error
We are getting crashes for multiple files when rendered using any version of 2.78 compiled against glibc 219. Latest version compiled with glibc 211 (2.78a) renders just fine. Errors we are getting look like these:

Fra:270 Mem:23.68M (0.00M, Peak 23.75M) | Time:00:00.01 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Updating Shaders
Error: run out of memory!
Fra:270 Mem:23.69M (0.00M, Peak 23.75M) | Time:00:00.01 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Cancel | Out of memory


Fra:54 Mem:3102.36M (0.00M, Peak 3142.88M) | Time:00:36.66 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Updating Shaders
terminate called after throwing an instance of 'std::bad_alloc'

Exact steps for others to reproduce the error
render from command line the attached .blend file with any official glibc 219 build.

CentOS 7 uses glibc 2.17, so a build with glibc 2.19 minimum will not work. builds currently do not support CentOS anymore, users need to make their own builds. See here for discussion on this:

In fact, it works on CentOS 7 for 99.95% of projects. It's just some of them that crash. We do render a significant number of projects (as in hundreds per day) and they are very varied, coming from lots of customers who use the RenderStreet service. I opened this bug hoping I would help you track why it crashes on these few cases.

I also find it odd that you drop support for the latest version of an OS that has 20% market share server side. Not everybody uses Blender on desktop.

Bastien Montagne (mont29) claimed this task.

Thanks for the report, but the assumption is that for companies running services like that, it should not be a big deal to make their own build of Blender (in fact, it would even be a really good idea, enabling you to do optimized builds for your specific hardware). Blender remains totally buildable with older glibc's.

GLibc 2.19 is already 3 years old, and is used by current Debian stable, we cannot get dragged back too much by 'server' OS's using five years old software… And we do not have the human power to maintain dozens of builds, release process is already enough heavy burden as it is currently for our team.

PS: If you want to discuss about that topic further, please consider using the ML (answering at thread pointed out by @Brecht Van Lommel (brecht)).

I can now confirm the same error will happen on the latest ubuntu as well. Slightly different error message though:

Error: run out of memory!
Fra:1 Mem:2868.06M (0.00M, Peak 2929.56M) | Time:00:31.56 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Cancel | Out of memory
Error: Out of memory
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)
# cat /etc/issue
Ubuntu 16.04.2 LTS
# ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu5) 2.23

Can this be considered for fixing now?


eeeh yes, then it’s not related to glibc at all! :)

Bastien Montagne (mont29) triaged this task as Confirmed priority.

Hrmppfff… tried both own release and debug builds with current master under debian testing, no problem.

But can confirm the crash with 2.78c official release under debian testing as well!

@Sergey Sharybin (sergey) think this one is for you? :|

Root of the issue was in OIIO which was over-allocating on attempt to open directory as WebP image while testing all possible plugins suitable for filepath.

For this issue i've prepared a patch for upstream:

For the time being i think we can avoid the crash by extra checks from our side. Will commit those shortly.