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 shotwell-0.20.2_1 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 :
Maintainer CC'd
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).
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.
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).
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. Thanks.
Ran make config and selected OpenMP and then did make install. Now it is working fine. So some sort of clang vs gcc issue.
(In reply to tonymaher from comment #6) To be clear I just recompiled shotwell with openmp selected.
(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.
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")
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 ${PORT_OPTIONS:MOPENMP} . if ${OPSYS} == FreeBSD [your stuff] . endif .endif that should be fine for dragonfly since it supports gomp in base.
A new upstream version has been committed, see https://svnweb.freebsd.org/changeset/ports/382548 This should fix the reported issue here in the process.