linux official build glibc 219 crash #50968

New Issue

Sorin Vinatoru · 2017-03-16T16:43:50+01:00

Sorin Vinatoru commented

2017-03-16 16:43:50 +01:00

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:

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

**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.blend](https://archive.blender.org/developer/F510845/27seasonsspring_RenderStreet.blend)

Sorin Vinatoru commented

2017-03-16 16:43:50 +01:00

Changed status to: 'Open'

Sorin Vinatoru commented

2017-03-16 16:43:50 +01:00

Added subscriber: @sorinv

Brecht Van Lommel commented

2017-03-17 01:59:30 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-03-17 01:59:31 +01:00

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

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 commented

2017-03-17 08:24:04 +01:00

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.

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 commented

2017-03-17 08:54:01 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2017-03-17 08:54:01 +01:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2017-03-17 08:54:01 +01:00

Bastien Montagne self-assigned this 2017-03-17 08:54:01 +01:00

Bastien Montagne commented

2017-03-17 08:54:01 +01:00

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.

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 commented

2017-03-17 08:55:21 +01:00

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

Sorin Vinatoru commented

2017-03-17 10:27:54 +01:00

Changed status from 'Archived' to: 'Open'

Sorin Vinatoru reopened this issue

2017-03-17 10:27:54 +01:00

Sorin Vinatoru commented

2017-03-17 10:27:54 +01:00

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

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 commented

2017-03-17 11:03:46 +01:00

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

Bastien Montagne removed their assignment 2017-03-17 12:43:36 +01:00

Sergey Sharybin was assigned by Bastien Montagne

2017-03-17 12:43:36 +01:00

Bastien Montagne commented

2017-03-17 12:43:36 +01:00

Added subscriber: @Sergey

Bastien Montagne commented

2017-03-17 12:43:36 +01:00

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 think this one is for you? :|

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 think this one is for you? :|

Sergey Sharybin commented

2017-03-17 14:42:53 +01:00

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.

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.

blender-admin commented

2017-03-17 14:47:12 +01:00

This issue was referenced by blender/cycles@05996080fc

This issue was referenced by blender/cycles@05996080fc2cdc983aa63ee83d6c4a1100260755

blender-admin commented

2017-03-17 14:47:12 +01:00

This issue was referenced by ea3d7a7f58

This issue was referenced by ea3d7a7f58f67b5ce690a92aa0e81e4bb836170b

Sergey Sharybin commented

2017-03-17 14:48:28 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2017-03-17 14:48:28 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

linux official build glibc 219 crash #50968