Bug 240466 - graphics/digikam: Segmentation fault on startup
Summary: graphics/digikam: Segmentation fault on startup
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-kde (group)
URL:
Keywords: crash, needs-qa
Depends on:
Blocks:
 
Reported: 2019-09-10 05:25 UTC by Dwayne MacKinnon
Modified: 2020-01-02 01:48 UTC (History)
7 users (show)

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


Attachments
Dr Konqi crash report, two stars (2.12 KB, text/plain)
2019-09-10 05:25 UTC, Dwayne MacKinnon
no flags Details
running in lldb (1.88 KB, text/plain)
2019-09-11 01:58 UTC, graham
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dwayne MacKinnon 2019-09-10 05:25:54 UTC
Created attachment 207342 [details]
Dr Konqi crash report, two stars

Whenever I open digikam (FreeBSD 12.0-RELEASE, amd64) version 6.3.0 it crashes immediately. showfoto from the same package also crashes immediately.

The problem seems to be related to libexiv from the graphics/exiv2 package. I've found the following error report but my crash happens on launch, not when browsing pictures.

http://digikam.1695700.n4.nabble.com/digikam-Bug-377432-New-Crash-on-browsing-images-td4694793.html

I've attached a crash report from Dr. Konqi.
Comment 1 graham 2019-09-10 09:35:22 UTC
I have exactly the same crash. I'm on 12-stable with ports and src as of this week. It's been the same for a few weeks now.
Comment 2 graham 2019-09-11 01:58:21 UTC
Created attachment 207366 [details]
running in lldb
Comment 3 Oleg Shelomov 2019-09-15 09:22:33 UTC
I used poudriere for the package. After package installation digikam-6.3.0 doesn't start:

~ % digikam
digikam.widgets: Use installed icons
[1]    1027 bus error  digikam

FreeBSD 11.2-RELEASE-p14 FreeBSD 11.2-RELEASE-p14 #0: Mon Aug 19 22:38:50 UTC 2019     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
Comment 4 elwood 2019-09-19 14:33:44 UTC
Same here:

[16:30 ~] # digikam
digikam.widgets: Use installed icons
Segmentation fault (core dumped)

FreeBSD 12.0-RELEASE-p10 r351572 amd64
Comment 5 Adriaan de Groot freebsd_committer freebsd_triage 2019-10-12 21:56:06 UTC
Here's a backtrace (after I rebuilt it with debugging symbols):

* thread #1, name = 'digikam', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000000800f821f1 libdigikamcore.so.6.4.0`::WXMPMeta_RegisterNamespace_1(namespaceURI="http://ns.adobe.com/lightroom/1.0/", suggestedPrefix="lr", registeredPrefix=0x00007fffffffd6a0, prefixSize=0x0000000000000001, wResult=0x0000000000000000) at WXMPMeta.cpp:224:5
   221                                 XMP_StringLen * prefixSize,
   222                                 WXMP_Result *   wResult )
   223  {
-> 224      XMP_ENTER_WRAPPER ( "WXMPMeta_RegisterNamespace_1" )
   225 
   226          if ( (namespaceURI == 0) || (*namespaceURI == 0) ) XMP_Throw ( "Empty namespace URI", kXMPErr_BadSchema );
   227          if ( (suggestedPrefix == 0) || (*suggestedPrefix == 0) ) XMP_Throw ( "Empty suggested prefix", kXMPErr_BadSchema );
(lldb) bt
* thread #1, name = 'digikam', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x0000000800f821f1 libdigikamcore.so.6.4.0`::WXMPMeta_RegisterNamespace_1(namespaceURI="http://ns.adobe.com/lightroom/1.0/", suggestedPrefix="lr", registeredPrefix=0x00007fffffffd6a0, prefixSize=0x0000000000000001, wResult=0x0000000000000000) at WXMPMeta.cpp:224:5
    frame #1: 0x0000000805825b44 libexiv2.so.27`Exiv2::XmpParser::initialize(void (*)(void*, bool), void*) + 132
    frame #2: 0x0000000800d30a0a libdigikamcore.so.6.4.0`Digikam::MetaEngine::initializeExiv2() at metaengine.cpp:84:10
    frame #3: 0x0000000000208d22 digikam`main(argc=1, argv=0x00007fffffffe458) at main.cpp:138:5
    frame #4: 0x000000000020810f digikam`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7

What's happening is that Exiv2::XmpParser::initialize() is calling WXMPMeta_RegisterNamespace_1 which is *supposed* to be a function inside Exiv2. Instead, it ends up in Digikam's reimplementation of that function (instead of Exiv2's version). And then it goes boom.
Comment 6 graham 2019-10-13 05:27:07 UTC
(In reply to Adriaan de Groot from comment #5)
 Ok, thanks Adrian.

I tried renaming DigiKam's WXMPMeta_RegisterNamespace_1 to WXMPMeta_RegisterNamespace_1a so that it wouldn't clash with the one in Exiv2. It now gets a little bit further. Again a SEGV at:

   1073
   1074     _LIBCPP_INLINE_VISIBILITY
   1075     __node_pointer __root() const _NOEXCEPT
-> 1076         {return static_cast<__node_pointer>(__end_node()->__left_);}
   1077
   1078     __node_base_pointer* __root_ptr() const _NOEXCEPT {
   1079         return _VSTD::addressof(__end_node()->__left_);

Backtrace:

* thread #1, name = 'digikam', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
  * frame #0: 0x0000000800ff6d85 libdigikamcore.so.6.3.0`std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::__root(this=0x0000000000000000) const at __tree:1076:59
    frame #1: 0x0000000800ff68b4 libdigikamcore.so.6.3.0`std::__1::__tree_node_base<void*>*& std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::__find_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(this=0x0000000000000000, __parent=0x00007fffffffd438, __v=0x00007fffffffd560) at __tree:2022:27
    frame #2: 0x0000000800ff66e3 libdigikamcore.so.6.3.0`std::__1::pair<std::__1::__tree_iterator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void*>*, long>, bool> std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::__emplace_unique_key_args<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::piecewise_construct_t const&, std::__1::tuple<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>, std::__1::tuple<> >(this=0x0000000000000000, __k=0x00007fffffffd560, __args=0x0000000800961970, __args=0x00007fffffffd4b0, __args=0x00007fffffffd4a8) at __tree:2151:36
    frame #3: 0x0000000800ff6650 libdigikamcore.so.6.3.0`std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::operator[](this=0x0000000000000000, __k=0x00007fffffffd560) at map:1484:20
    frame #4: 0x0000000805c193b5 libexiv2.so.27`XMPMeta::RegisterNamespace(namespaceURI="http://ns.adobe.com/lightroom/1.0/", prefix="lr") at XMPMeta.cpp:1052:9
    frame #5: 0x0000000805bdf361 libexiv2.so.27`::WXMPMeta_RegisterNamespace_1(namespaceURI="http://ns.adobe.com/lightroom/1.0/", prefix="lr", wResult=0x00007fffffffd660) at WXMPMeta.cpp:228:3
    frame #6: 0x0000000805ba8358 libexiv2.so.27`TXMPMeta<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::RegisterNamespace(namespaceURI="http://ns.adobe.com/lightroom/1.0/", prefix="lr") at TXMPMeta.incl_cpp:240:2
    frame #7: 0x0000000805ba373f libexiv2.so.27`Exiv2::XmpParser::initialize(xmpLockFct=0x0000000000000000, pLockData=0x0000000000000000)(void*, bool), void*) at xmp.cpp:451:13
    frame #8: 0x0000000800d99138 libdigikamcore.so.6.3.0`Digikam::MetaEngine::initializeExiv2() at metaengine.cpp:84:10
    frame #9: 0x0000000000208d2d digikam`main(argc=1, argv=0x00007fffffffe418) at main.cpp:138:5
    frame #10: 0x000000000020810f digikam`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7
Comment 7 commit-hook freebsd_committer freebsd_triage 2019-10-13 08:41:33 UTC
A commit references this bug:

Author: adridg
Date: Sun Oct 13 08:41:23 UTC 2019
New revision: 514373
URL: https://svnweb.freebsd.org/changeset/ports/514373

Log:
  Try to fix runtime graphics/digikam.

  With this patch applied to git master, digikam starts and seems
  to work. It still crashes on exit, though. That's an improvement
  on crashes-before-startup.

  The problem is described in the patch and in the PR: digikam
  bundles all kinds of stuff (which packagers have been complaining
  about for years) which breaks -- in this case, bundling internals
  of Exiv2.

  If this works (leaving the PR open) it will need an MFH.

  PR:		240466

Changes:
  head/graphics/digikam/Makefile
  head/graphics/digikam/files/patch-remove-libxmp
Comment 8 Adriaan de Groot freebsd_committer freebsd_triage 2020-01-02 01:48:27 UTC
Resolved by Digikam 6.4.0 in ports