Maniphest T50968

linux official build glibc 219 crash
Closed, ResolvedPublic
Actions

Description

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

or

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.

27seasonsspring_RenderStreet.blend8 MB

Details

Commits
rC05996080fc2c: Fix T50968: Cycles crashes when image datablock points to a directory
rBea3d7a7f58f6: Fix T50968: Cycles crashes when image datablock points to a directory
Type
Bug

Related Objects

Brecht Van Lommel (brecht) added a subscriber: Brecht Van Lommel (brecht).Mar 17 2017, 1:59 AM

CentOS 7 uses glibc 2.17, so a build with glibc 2.19 minimum will not work.

blender.org builds currently do not support CentOS anymore, users need to make their own builds. See here for discussion on this:
https://lists.blender.org/pipermail/bf-committers/2016-October/047716.html

Sorin Vinatoru (sorinv) added a comment.Mar 17 2017, 8:24 AM

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) closed this task as Invalid.Mar 17 2017, 8:54 AM
Bastien Montagne (mont29) claimed this task.
Bastien Montagne (mont29) added a subscriber: Bastien Montagne (mont29).

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.

Bastien Montagne (mont29) added a comment.Mar 17 2017, 8:55 AM

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

Sorin Vinatoru (sorinv) reopened this task as Open.Mar 17 2017, 10:27 AM

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?

Thanks

Bastien Montagne (mont29) added a comment.Mar 17 2017, 11:03 AM

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

Bastien Montagne (mont29) reassigned this task from Bastien Montagne (mont29) to Sergey Sharybin (sergey).Mar 17 2017, 12:43 PM
Bastien Montagne (mont29) triaged this task as Confirmed priority.
Bastien Montagne (mont29) added a subscriber: Sergey Sharybin (sergey).

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? :|

Sergey Sharybin (sergey) added a comment.Mar 17 2017, 2:42 PM

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: https://github.com/OpenImageIO/oiio/pull/1640

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