Bug 196236 - graphics/shotwell: Segmentation fault
Summary: graphics/shotwell: Segmentation fault
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
Keywords: needs-patch, needs-qa
Depends on:
Reported: 2014-12-23 19:58 UTC by tonymaher
Modified: 2015-03-28 19:49 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (cmt)

fix compiler&libs, pet portscout (737 bytes, patch)
2015-02-23 22:04 UTC, Christoph Moench-Tegeder
cmt: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tonymaher 2014-12-23 19:58:18 UTC
uname -a
FreeBSD zen.home 9.3-RELEASE-p5 FreeBSD 9.3-RELEASE-p5 #0: Mon Nov  3 22:38:58 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

pkg info shotwell
Name           : shotwell
Version        : 0.20.2_1
Installed on   : Tue Dec 23 15:25:54 EST 2014
Origin         : graphics/shotwell
Architecture   : freebsd:9:x86:64
Prefix         : /usr/local

showell opens ok but crashes when trying to import new photos or view existing ones.  Was working about a month ago (from fading memory).
Installed as package and built locally same problem.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 815c07400 (LWP 100912/shotwell)]
0x0000000000000000 in ?? ()
(gdb) backtrace
#0  0x0000000000000000 in ?? ()
#1  0x000000081594dce1 in __dynamic_cast () from /usr/lib/libsupc++.so.1
#2  0x000000080126f6bc in Exiv2::Internal::TiffSubIfd::doAddChild () from /usr/local/lib/libexiv2.so.13
#3  0x0000000801270ddf in Exiv2::Internal::TiffComponent::addChild () from /usr/local/lib/libexiv2.so.13
#4  0x000000080128def6 in Exiv2::Internal::TiffReader::visitSubIfd () from /usr/local/lib/libexiv2.so.13
#5  0x000000080126f10c in Exiv2::Internal::TiffSubIfd::doAccept () from /usr/local/lib/libexiv2.so.13
#6  0x000000080126ef68 in Exiv2::Internal::TiffDirectory::doAccept () from /usr/local/lib/libexiv2.so.13
#7  0x0000000801279a6e in Exiv2::Internal::TiffParserWorker::parse () from /usr/local/lib/libexiv2.so.13
#8  0x000000080127ab67 in Exiv2::Internal::TiffParserWorker::decode () from /usr/local/lib/libexiv2.so.13
#9  0x000000080127acc3 in Exiv2::TiffParser::decode () from /usr/local/lib/libexiv2.so.13
#10 0x00000008011e278a in Exiv2::ExifParser::decode () from /usr/local/lib/libexiv2.so.13
#11 0x00000008011f60e8 in Exiv2::JpegBase::readMetadata () from /usr/local/lib/libexiv2.so.13
#12 0x0000000800eb39dd in gexiv2_metadata_open_internal () from /usr/local/lib/libgexiv2.so.2
#13 0x0000000800eb3d96 in gexiv2_metadata_open_path () from /usr/local/lib/libgexiv2.so.2
#14 0x00000000004db06a in photo_metadata_get_type ()
#15 0x00000000004e667d in gdk_reader_get_type ()
#16 0x00000000005f5bca in photo_set_default_raw_developer ()
#17 0x00000000006457f3 in basic_properties_get_type ()
#18 0x00000000006462fb in properties_get_single_properties ()
#19 0x0000000000644cce in basic_properties_get_type ()
#20 0x000000000064821a in properties_add_line ()
#21 0x000000000064651c in properties_update_properties ()
#22 0x00000000004fe52c in library_window_new ()
#23 0x00000000004846f9 in value_set_one_shot_scheduler ()
#24 0x00000008085363b4 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0
#25 0x000000080853839a in g_main_context_acquire () from /usr/local/lib/libglib-2.0.so.0
#26 0x0000000808538467 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0
#27 0x00000008075e910c in g_application_run () from /usr/local/lib/libgio-2.0.so.0
#28 0x00000000006aeb95 in application_start ()
#29 0x000000000059ae50 in library_exec ()
#30 0x000000000059b484 in _vala_main ()
#31 0x000000000059b6f1 in main ()

Looks to be problem in graphics/exiv2 but can run ok on cammnad line

exiv2 IMG_0010.JPG
File name       : IMG_0010.JPG
File size       : 3372498 Bytes
MIME type       : image/jpeg
Image size      : 3888 x 2592
Camera make     : Canon
Camera model    : Canon EOS 1000D
Image timestamp : 2014:12:21 05:13:10
Image number    : 
Exposure time   : 1/2 s
Aperture        : F3.5
Exposure bias   : -1/3 EV
Flash           : No, compulsory
Flash bias      : 0 EV
Focal length    : 18.0 mm
Subject distance: 0
ISO speed       : 800
Exposure mode   : Auto
Metering mode   : Multi-segment
Macro mode      : Off
Image quality   : Fine
Exif Resolution : 3888 x 2592
White balance   : Auto
Thumbnail       : image/jpeg, 5807 Bytes
Copyright       : 
Exif comment    :
Comment 1 Bugzilla Automation freebsd_committer 2014-12-23 19:58:18 UTC
Maintainer CC'd
Comment 2 Christoph Moench-Tegeder freebsd_committer 2014-12-24 13:49:28 UTC
I'm even sure it did "work for me" as of last week.
I'll have a look into the issue once I get back to my own "real" shotwell installation.
From the backtrace alone - is it possible you have some mix of gcc/clang compiled libraries? (not that I'm in any way sure that this is the issue, but I have seen similar crashes while experimenting with OpenMP-enabled (gcc-compiled) libraw, when using the wrong mix of options across ports).
Comment 3 tonymaher 2014-12-24 15:38:17 UTC
How do you tell which compiler has been used?
I have mostly been using prebuilt packages.  The only ones compiled locally were ones that did not have a package.
I did try earlier to reinstall/rebuild using portupgrade and some did compile locally (ports more recent than packages) to see if that fixed the problem. It did not.
Comment 4 Christoph Moench-Tegeder freebsd_committer 2014-12-28 18:55:55 UTC
I cannot reproduce your problem with my files on my installation. Can you attach a testcase (some image file triggering the bug)?
For reference, I'm using shotwell compiled with gcc, as my libraw has OpenMP support activated. I'm not sure about the default options, but you might want to check if shotwell and/or libraw are linked against libgcc_s.so and possibly libgomp.so (yes, libgomp - the GNU OpenMP library).
Comment 5 tonymaher 2014-12-28 22:43:09 UTC
ldd /usr/local/bin/shotwell | grep libgcc_s.so
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x808f76000)
ldd /usr/local/lib/libraw.so.9  | grep libgcc_s.so
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801c4d000)
ldd /usr/local/lib/libraw.so.9 | grep libgomp
ldd /usr/local/bin/shotwell | grep libgomp

Any image causes it to crash.

If I try to compile libraw it uses c++ (no openmp defined).
Cannot work out hpow to override that.

Comment 6 tonymaher 2015-01-06 03:51:48 UTC
Ran make config and selected OpenMP and then did make install.
Now it is working fine.  So some sort of clang vs gcc issue.
Comment 7 tonymaher 2015-01-06 04:02:46 UTC
(In reply to tonymaher from comment #6)
To be clear I just recompiled shotwell with openmp selected.
Comment 8 Christoph Moench-Tegeder freebsd_committer 2015-01-06 21:22:16 UTC
(In reply to tonymaher from comment #7)

Ah, now... I completely missed that you have the ancient gcc as a default compiler (I'm on FreeBSD 10.1, so I've got clang since 10BETA or so).
So I think it's not a case of "clang vs. gcc" (you would need to switch the default compiler on your own for that, I don't think official packages would be built that way), but it's totally possible that "some update" (there was the huge GNOME-update, including vala, for example) made shotwell or one of it's dependencies trigger a bug in the ancient gcc or it's libraries.
I think it might be neccessary to force USE_GCC at least on FreeBSD 9. I'll have to check if there are drawbacks if I set USE_GCC unconditionally.
Comment 9 Christoph Moench-Tegeder freebsd_committer 2015-02-23 22:04:47 UTC
Created attachment 153401 [details]
fix compiler&libs, pet portscout

- fix crash described here (at least I cannot reproduce it anymore in a VM)
- fix build after webkit-gtk3 upgrade (#196707)
- add portscout info (shotwell 0.21 is described as an "unstable pre-release")
Comment 10 John Marino freebsd_committer 2015-03-01 21:46:12 UTC
This doesn't look right to me.

1) the whole point of using USES=compiler: is to avoid having to use OSVERSION.  you have OSVERSION check before setting USES=compiler

2) You use OSVERSION without checking OPSYS.  This breaks OPSYS=DragonFly.

3) More DragonFly incompatibility -- DragonFly has libgomp in base and does not have libc++ 

I would say at the very least do something like:

. if ${OPSYS} == FreeBSD
[your stuff]
. endif

that should be fine for dragonfly since it supports gomp in base.
Comment 11 Thomas Zander freebsd_committer 2015-03-28 19:49:23 UTC
A new upstream version has been committed, see
This should fix the reported issue here in the process.