Page MenuHome

Moving objects to another layer crashes Blender
Closed, ResolvedPublic


How to reproduce:

  1. start Blender on Arch Linux 64-bit
  2. select the default cube
  3. press m and 3
  4. Blender crashes always


Blender 2.70 (sub 0), Commit date: 2014-04-10 11:49, Hash f93bc76

bpy.ops.object.move_to_layer(layers=(False, False, True, False, False, False, False, False, False, False, False, False, False, False, False, False, False, False, False, False)) # Operator


blender() [0x8c64c3]
/usr/lib/ [0x7fc52ddb0df0]
blender(MEM_lockfree_freeN+0x28) [0x11c5958]
blender(RNA_path_full_property_py+0x72) [0x140c9d2]
blender(WM_prop_pystring_assign+0x9e) [0x8dbf0e]
blender() [0xa6041c]
blender() [0xa66224]
blender() [0xa6bf1f]
blender() [0xa6ca04]
blender() [0xa6cc27]
blender() [0xa6e220]
blender() [0x8cf062]
blender() [0x8cf378]
blender(wm_event_do_handlers+0x1cc) [0x8cf67c]
blender(WM_main+0x18) [0x8c83f8]
blender(main+0xd6f) [0x8afc6f]
/usr/lib/ [0x7fc52dd9d000]
blender() [0x8c5d14]

My environment is Arch Linux 64-bit. Libraries used by Blender:

$ ldd which blender (0x00007fff5f1fe000) => /usr/lib/ (0x00007f3abc53f000) => /usr/lib/ (0x00007f3abc2c0000) => /usr/lib/ (0x00007f3abc08b000) => /usr/lib/ (0x00007f3abbe75000) => /usr/lib/ (0x00007f3abbbcc000) => /usr/lib/ (0x00007f3abb742000) => /usr/lib/ (0x00007f3abb4b6000) => /usr/lib/ (0x00007f3abb25e000) => /usr/lib/ (0x00007f3abae5d000) => /usr/lib/ (0x00007f3abac3d000) => /usr/lib/ (0x00007f3aba9d5000) => /usr/lib/ (0x00007f3aba73d000) => /usr/lib/ (0x00007f3aba51f000) => /usr/lib/ (0x00007f3aba2ab000) => /usr/lib/ (0x00007f3ab99e0000) => /usr/lib/ (0x00007f3ab978b000) => /usr/lib/ (0x00007f3ab9574000) => /usr/lib/ (0x00007f3ab9370000) => /usr/lib/ (0x00007f3ab9158000) => /usr/lib/ (0x00007f3ab8e7e000) => /usr/lib/ (0x00007f3ab8c3b000) => /usr/lib/ (0x00007f3ab8a1a000) => /usr/lib/ (0x00007f3ab8708000) => /usr/lib/ (0x00007f3ab83b6000) => /usr/lib/ (0x00007f3ab818d000) => /usr/lib/ (0x00007f3ab7e04000) => /usr/lib/ (0x00007f3ab6d41000) => /usr/lib/ (0x00007f3ab6aee000) => /usr/lib/ (0x00007f3ab68d9000) => /usr/lib/ (0x00007f3ab666b000) => /usr/lib64/opencollada/ (0x00007f3ab6405000) => /usr/lib64/opencollada/ (0x00007f3ab57e8000) => /usr/lib64/opencollada/ (0x00007f3ab55a6000) => /usr/lib64/opencollada/ (0x00007f3ab5388000) => /usr/lib64/opencollada/ (0x00007f3ab5176000) => /usr/lib/ (0x00007f3ab4f16000) => /usr/lib/ (0x00007f3ab4b50000) => /usr/lib/ (0x00007f3ab492d000) => /usr/lib/ (0x00007f3ab45f2000) => /usr/lib/ (0x00007f3ab43e2000) => /usr/lib/ (0x00007f3ab41dc000) => /usr/lib/ (0x00007f3ab3fd8000) => /usr/lib/ (0x00007f3ab3c2a000) => /usr/lib/ (0x00007f3ab3926000) => /usr/lib/ (0x00007f3ab361b000) => /usr/lib/ (0x00007f3ab3406000) => /usr/lib/ (0x00007f3ab31f0000) => /usr/lib/ (0x00007f3ab2fed000) => /usr/lib/ (0x00007f3ab042f000) => /usr/lib/ (0x00007f3ab021d000) => /usr/lib/ (0x00007f3ab000d000) => /usr/lib/ (0x00007f3aafdb7000) => /usr/lib/ (0x00007f3aafbb4000) => /usr/lib/ (0x00007f3aaf999000) => /usr/lib/ (0x00007f3aaf791000) => /usr/lib/ (0x00007f3aaf3dd000) => /usr/lib/ (0x00007f3aaf1ab000) => /usr/lib/ (0x00007f3aaef02000) => /usr/lib/ (0x00007f3aaecd5000) => /usr/lib/ (0x00007f3aaeace000)
/lib64/ (0x00007f3abc877000) => /usr/lib/ (0x00007f3aae8ab000) => /usr/lib/ (0x00007f3aae59c000) => /usr/lib/ (0x00007f3aae196000) => /usr/lib/ (0x00007f3aadf8e000) => /usr/lib/ (0x00007f3aadc13000) => /usr/lib/ (0x00007f3aad7e1000) => /usr/lib/ (0x00007f3aac159000) => /usr/lib/ (0x00007f3aabf47000) => /usr/lib/ (0x00007f3aabd42000) => /usr/lib/ (0x00007f3aabb3b000) => /usr/lib/ (0x00007f3aab91f000) => /usr/lib/ (0x00007f3aab593000) => /usr/lib/ (0x00007f3aab361000) => /usr/lib/ (0x00007f3aab04b000) => /usr/lib/ (0x00007f3aaae35000) => /usr/lib/ (0x00007f3aaab1f000) => /usr/lib/ (0x00007f3aaa6ac000) => /usr/lib/ (0x00007f3aaa33a000) => /usr/lib/ (0x00007f3aa9f56000) => /usr/lib/ (0x00007f3aa9d15000) => /usr/lib/ (0x00007f3aa9afc000) => /usr/lib/ (0x00007f3aa98e3000) => /usr/lib/ (0x00007f3aa961a000) => /usr/lib/ (0x00007f3aa93ce000) => /usr/lib/ (0x00007f3aa91ba000) => /usr/lib/ (0x00007f3aa8f90000) => /usr/lib/ (0x00007f3aa8d19000) => /usr/lib/ (0x00007f3aa8b0e000) => /usr/lib/ (0x00007f3aa8802000) => /usr/lib/ (0x00007f3aa85fc000) => /usr/lib/ (0x00007f3aa8305000) => /usr/lib/ (0x00007f3aa80f7000) => /usr/lib/ (0x00007f3aa7ef3000) => /usr/lib/ (0x00007f3aa7ca8000) => /usr/lib64/opencollada/ (0x00007f3aa7aa0000) => /usr/lib64/opencollada/ (0x00007f3aa7850000) => /usr/lib/ (0x00007f3aa75e6000) => /usr/lib64/opencollada/ (0x00007f3aa73e3000) => /usr/lib/ (0x00007f3aa707b000) => /usr/lib/ (0x00007f3aa5432000) => /usr/lib/ (0x00007f3aa5212000) => /usr/lib/ (0x00007f3aa4f0a000) => /usr/lib/ (0x00007f3aa4cec000) => /usr/lib/ (0x00007f3aa4a85000) => /usr/lib/ (0x00007f3aa4818000) => /usr/lib/ (0x00007f3aa45d6000) => /usr/lib/ (0x00007f3aa43c2000) => /usr/lib/ (0x00007f3aa4194000) => /usr/lib/ (0x00007f3aa3f65000) => /usr/lib/ (0x00007f3aa3cee000) => /usr/lib/ (0x00007f3aa3a68000) => /usr/lib/ (0x00007f3aa3850000) => /usr/lib/ (0x00007f3aa3632000) => /usr/lib/ (0x00007f3aa3414000) => /usr/lib/ (0x00007f3aa31f4000) => /usr/lib/ (0x00007f3aa2fb7000) => /usr/lib/ (0x00007f3aa2d3e000) => /usr/lib/pulseaudio/ (0x00007f3aa2aca000) => /usr/lib/ (0x00007f3aa28bf000) => /usr/lib/ (0x00007f3aa2678000) => /usr/lib64/opencollada/ (0x00007f3aa2474000) => /usr/lib/ (0x00007f3aa226c000) => /usr/lib/ (0x00007f3aa2007000) => /usr/lib/ (0x00007f3aa1e03000) => /usr/lib/ (0x00007f3aa1bfd000) => /usr/lib/ (0x00007f3aa19f5000) => /usr/lib/ (0x00007f3aa17d9000) => /usr/lib/ (0x00007f3aa15c1000) => /usr/lib/ (0x00007f3aa138e000) => /usr/lib/ (0x00007f3aa1164000) => /usr/lib/ (0x00007f3abca04000) => /usr/lib/ (0x00007f3aa0f5e000) => /usr/lib/ (0x00007f3aa0d59000) => /usr/lib/ (0x00007f3aa0a7b000) => /usr/lib/ (0x00007f3aa0876000) => /usr/lib/ (0x00007f3aa065e000) => /usr/lib/ (0x00007f3aa0447000)


$ uname -a
Linux visentti 3.14.4-1-ARCH #1 SMP PREEMPT Tue May 13 16:41:39 CEST 2014 x86_64 GNU/Linux

Related Objects

Event Timeline

Timo Saarinen (timosa75) set Type to Bug.
Timo Saarinen (timosa75) created this task.
Timo Saarinen (timosa75) raised the priority of this task from to Needs Triage by Developer.

Can’t reproduce on Debian wheezy 64… Campbell, think you are using Arch too?

I can reproduce this on Arch Linux every time, along with other semi-random crashes. Starting/restarting the game engine also occasionally crashes Blender for me. That happens a lot more on my desktop computer than my laptop. My desktop has an ATI/AMD graphics card, and my laptop has an Intel graphics card. They are both running Arch.

I can reproduce this on two independent Arch Linux 64 installations. The other has Intel graphics and the other nVidia. Some days ago all worked as expected. Here are some Blender-related dependencies (/var/log/pacman.log), that were updated recently, if they are helpful for you.

[2014-05-11 10:25] [PACMAN] upgraded sdl (1.2.15-5 -> 1.2.15-6)
[2014-05-12 18:20] [PACMAN] upgraded libxcb (1.10-1 -> 1.10-2)
[2014-05-12 18:20] [PACMAN] upgraded libva (1.3.0-1 -> 1.3.1-1)
[2014-05-14 08:30] [PACMAN] upgraded libdbus (1.8.0-1 -> 1.8.2-1)
[2014-05-15 21:37] [PACMAN] upgraded openimageio (1.3.13-1 -> 1.4.5.git-1)
[2014-05-15 21:38] [PACMAN] upgraded blender (14:2.70a-1 -> 14:2.70a-2)

And this one too...

[2014-05-15 21:37] [PACMAN] upgraded openshadinglanguage (1.5.4dev-1 -> 1.5.7dev-1)

No crash with the same version on Ubuntu 12.10 x86-64 and Ubuntu 14.04 x86-64.

Crashes on 32 bit Arch Linux as well. Here is the related bug in Arch Linux bug system. The packager suspects gcc 4.9 related problem.

Bastien Montagne (mont29) triaged this task as Normal priority.May 18 2014, 9:24 AM

I can also confirm this bug on Arch Linux 64.

Blender version (from pacman): 14:2.70a-2
Arch: x86_64

Looks like it segfaults on Group creation too (see T40250)…

Campbell, assigning to you, afaik you are our main Arch dev?

I'm also on Arch 64 and have this problem too for some time now, on my own compiled Blender-master. Crashes/segfaults consistently, not only when moving an object to another layer, but also when subdividing and then increasing the cuts. Downloading from does not have these crashes.

Hi, I'm the Blender package maintainer in Arch. I fixed our package by forcing -O1 for now and it seems to work. This is obviously not preferable. I'm pretty sure this isn't anything Arch specific but rather a new property to gcc 4.9's optimizing options. I'm not sure which optimization causes this and I can't really investigate as well as you guys could.

This is a bug that eventually all other distros will run into once they finally upgrade to gcc 4.9 and should be fixed by Blender. Using -O1 is not a fix, only a workaround.

@Sven-Hendrik Haase (svenstaro), hi, I use arch for my main workstation, seems massing a NULL string (%s) to vsnprintf functions is cause of crash.


printf("%s\n", NULL);

Note. previous fix was wrong, committed a correct fix (bad use of nonnull attribute)


This is only a compile-time test for the most trivial cases. Some similar bugs could remain hidden. And maybe many other builtins are affected.

@Fazekas Laszlo (totoro), not sure what you mean. Incorrect use of nonnull attribute can cause crashes, but I checked for other similar cases to this and couldn't find any.

As says, the nonnull attribute is only a simple compile-time test. I'm sure it can find a NULL only if the argument is a constant (even through a variable etc. but its origin must be a static const). The side effect is at the optimization: the compiler gets a (maybe false) info that the argument is surely not null and uses this to simplify the code. Sometimes this means removing important null checkings. What if the function with the attribute actually can accept null as an argument (@Sven-Hendrik Haase (svenstaro) 's example is memmove() with zero length: obviously won't crash with a null) and the new optimization policy causes hardly detectable bugs.

Maybe this is okay and not a serious problem anyway. Also I hope gcc will find a better way to optimize in the next version (for example not removing explicit null checkings).

@Fazekas Laszlo (totoro)

As far as I can see, GCC is correct and blender was wrong.

  • GCC uses nonnull to tag a variable as never being NULL.
  • Blender incorrectly marked all args to BLI_sprintfN as nonnull.
  • GCC optimized out a NULL check later on (after that argument was passed to BLI_sprintfN)

I'm certain of this because I double checked this and found if (data_path != NULL) { printf("%p", data_path); } ignored the if check and printed 0x0.

Though it would be nice if GCC could optionally warn of redundant NULL checks.