Bug#914190: blender: Crashes on startup
On Tue, 20 Nov 2018 22:45:46 +0100 "Matteo F. Vescovi" <mfv@debian.org> wrote:
> Hi again!
>
> On 2018-11-20 at 18:55 (+0100), Lucio Crusca wrote:
> > On 20/11/18 18:06, Matteo F. Vescovi wrote:
> >> Is it ok for you, Lucio?
> >
> > Yes, no problem, I can wait. Thanks.
>
> Meanwhile, I figured out what's the problem here: OpenColorIO library.
>
> A rebuild+install on up-to-date unstable/sid machine of that library
> made Blender run back again.
>
> I'll ask for a give-back on all architectures, since OCIO seems to be
> not part of any transition, at the moment.
Normally when a rebuild fixes a problem like this, there's probably an ABI break somewhere, which needs to be addressed properly.
Thread 1 "blender" received signal SIGSEGV, Segmentation fault.
YAML::detail::node_data::get<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (pMemory=..., key="ocio_profile_version", this=<optimized out>) at /usr/include/yaml-cpp/node/detail/impl.h:91
91 /usr/include/yaml-cpp/node/detail/impl.h: No such file or directory.
(gdb) bt
#0 0x00007ffff4dc95e2 in YAML::detail::node_data::get<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::shared_ptr<YAML::detail::memory_holder>) const (pMemory=..., key="ocio_profile_version", this=<optimized out>)
at /usr/include/yaml-cpp/node/detail/impl.h:91
#1 0x00007ffff4dc95e2 in YAML::detail::node_ref::get<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::shared_ptr<YAML::detail::memory_holder>) const (pMemory=..., key="ocio_profile_version", this=<optimized out>)
at /usr/include/yaml-cpp/node/detail/node_ref.h:61
#2 0x00007ffff4dc95e2 in YAML::detail::node::get<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::shared_ptr<YAML::detail::memory_holder>) const (pMemory=..., key="ocio_profile_version", this=<optimized out>)
at /usr/include/yaml-cpp/node/detail/node.h:121
#3 0x00007ffff4dc95e2 in YAML::Node::operator[]<char [21]>(char const (&) [21]) const (this=this@entry=0x7fffffffdbc0, key=...) at /usr/include/yaml-cpp/node/impl.h:370
#4 0x00007ffff4dc2b1d in OpenColorIO::v1::(anonymous namespace)::load(YAML::Node const&, OpenColorIO::v1::ConfigRcPtr&, char const*) (node=..., c=std::tr1::shared_ptr<OpenColorIO::v1::Config> (use count 1, weak count 0) = {...}, filename=filename@entry=0x7fffffffe200 "/usr/share/blender/datafiles/colormanagement/config.ocio") at ./src/core/OCIOYaml.cpp:1445
#5 0x00007ffff4dc669d in OpenColorIO::v1::OCIOYaml::open(std::istream&, std::tr1::shared_ptr<OpenColorIO::v1::Config>&, char const*) const (this=<optimized out>, istream=..., c=std::tr1::shared_ptr<OpenColorIO::v1::Config> (use count 1, weak count 0) = {...}, filename=filename@entry=0x7fffffffe200 "/usr/share/blender/datafiles/colormanagement/config.ocio")
at ./src/core/OCIOYaml.cpp:1841
#6 0x00007ffff4d3fa63 in OpenColorIO::v1::Config::CreateFromFile(char const*) (filename=0x7fffffffe200 "/usr/share/blender/datafiles/colormanagement/config.ocio") at ./src/core/Config.cpp:385
#7 0x000055555801f37f in OCIOImpl::configCreateFromFile(char const*) ()
#8 0x0000555556fc3d3a in colormanagement_init ()
#9 0x00005555565a3fe2 in main ()
(gdb) quit
The crash is happening in libyaml-cpp.
ii libyaml-cpp0.5v5:amd64 0.5.3-0.1 amd64 YAML parser and emitter for C++
Note that that was updated to 0.5.3 two days ago. Downgrading to the
version in testing fixes this crash. So it seems like yaml-cpp broke
the ABI in 0.5.3 if a rebuild of opencolorio against the new version
solves the crash.
I have noticed that both yaml-cpp and opencolorio build-dep on libboost-dev,
but they don't depend on any boost package. If yaml-cpp is exposing some
boost symbols in its own ABI, it could need a SONAME bump for every
boost transition.
Cheers,
Emilio
Reply to: