Variety segfaults on libexiv/std::_Rb_tree on autostart, but not when started manually

[Raony Guimarães]

Crashed on startup

ProblemType: Crash
DistroRelease: Ubuntu 16.04
Package: variety 0.6.0-1
ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2
Uname: Linux 4.4.0-8-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CurrentDesktop: MATE
Date: Wed Mar 2 11:55:04 2016
ExecutablePath: /usr/bin/variety
InstallationDate: Installed on 2016-02-26 (4 days ago)
InstallationMedia: Ubuntu-MATE 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160224)
InterpreterPath: /usr/bin/python2.7
PackageArchitecture: all
ProcCmdline: /usr/bin/python /usr/bin/variety
SegvAnalysis:
 Segfault happened at: 0x7f19f186a251: movdqu -0x1e(%rdi),%xmm2
 PC (0x7f19f186a251) ok
 source "-0x1e(%rdi)" (0x00000008) not located in a known VMA region (needed readable region)!
 destination "%xmm2" ok
 Stack memory exhausted (SP below stack segment)
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: variety
Title: variety crashed with SIGSEGV in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_get_insert_hint_unique_pos()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[James Lu (jlu5)]

Hi everyone,

A cursory glance of the backtrace logs points to libexiv2 being the issue. Unfortunately, exiv2's maintainer seems overwhelmed or unwilling to harden the library, and thus it has many documented issues handling malformed data. Nevertheless, many programs depend on it either directly or transitively via wrappers - in this case, Variety is using it via GExiv2. https://bugzilla.gnome.org/show_bug.cgi?id=785547 and http://dev.exiv2.org/issues/1248 have more background on the issue.

For us to fix these problems would likely involve either porting to a different EXIF framework (Python-native examples: [1][2]), or dropping our use of EXIF metadata entirely[3].

[1]: https://github.com/ianare/exif-py
[2]: https://pypi.python.org/pypi/pexif
[3]: https://bugs.launchpad.net/variety/+bug/1593254

[Peter Levi (peterlevi)]

We can't drop our use of EXIF, it's essential - Variety uses EXIF metadata inside the images to store info about where the image is downloaded from, what the source URL and Author is, etc. EXIF is definitely the most appropriate place for this, as it "moves" along with the image when a user starts reorganizing their collection, and it also ensures that author attribution, whenever present, persists if the user uploads the image somewhere.

[James Lu (jlu5)]

Oh, I misread #1593254. Never mind then

[Peter Levi (peterlevi)]

To everyone experiencing this:

Do you still experience it with Variety and your OS's current versions?

If you increase the autostart delay in Variety's autostart desktop entry (~/.config/autostart/variety.desktop) from 20 seconds to something larger (i.e. allow system to settle completely before starting Variety), does this problem still happen?