| Summary: | graphics/digikam: Segmentation fault on startup | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dwayne MacKinnon <dmk> | ||||||
| Component: | Individual Port(s) | Assignee: | freebsd-kde (group) <kde> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | adridg, andreas, dbarelop, elwood, forum3, graham, jmc-freebsd2 | ||||||
| Priority: | --- | Keywords: | crash, needs-qa | ||||||
| Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(kde) |
||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
|
Description
Dwayne MacKinnon
2019-09-10 05:25:54 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. Created attachment 207366 [details]
running in lldb
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 Same here: [16:30 ~] # digikam digikam.widgets: Use installed icons Segmentation fault (core dumped) FreeBSD 12.0-RELEASE-p10 r351572 amd64 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.
(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 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 Resolved by Digikam 6.4.0 in ports |