Bug 1697484

Summary: [abrt] tracker-miners: tracker-extract keeps crashing and flooding journal
Product: [Fedora] Fedora Reporter: Francesco <frapox>
Component: tracker-minersAssignee: Kalev Lember <klember>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: debarshir, gnome-sig, kevin.v, klember
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/f680074ad4c58ee9efd346ce6a49c8e81a909efe
Whiteboard: abrt_hash:c6fd22b634017146b2674012e6d4fd172d851f30;
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-27 22:01:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: cpuinfo
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: mountinfo
none
File: open_fds
none
File: proc_pid_status none

Description Francesco 2019-04-08 13:54:55 UTC
Description of problem:
Login to a session, and tracker-extract begin to index files. It keeps crashing, flooding a lot the journal.
No other manual operations required.

Version-Release number of selected component:
tracker-miners-2.1.6-1.fc29

Additional info:
reporter:       libreport-2.10.0
backtrace_rating: 4
cmdline:        /usr/libexec/tracker-extract
crash_function: 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> > > > >::lower_bound
executable:     /usr/libexec/tracker-extract
journald_cursor: s=e8f5c7ce77bd4c5aa2947e953f902ffe;i=f0cc;b=c536febf77794e00a4f8be5635eb8ddb;m=53b6b78f;t=5860358569e65;x=a05d96e4a2f296ee
kernel:         5.0.5-200.fc29.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 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> > > > >::lower_bound at /usr/include/c++/8/bits/stl_tree.h:1202
 #1 std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, 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> > > > >::lower_bound at /usr/include/c++/8/bits/stl_map.h:1240
 #2 std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, 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> > > > >::operator[] at /usr/include/c++/8/bits/stl_map.h:495
 #3 XMPMeta::RegisterNamespace at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/xmpsdk/src/XMPMeta.cpp:1048
 #4 WXMPMeta_RegisterNamespace_1 at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/xmpsdk/src/WXMPMeta.cpp:228
 #5 TXMPMeta<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::RegisterNamespace at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/xmpsdk/include/client-glue/WXMP_Common.hpp:29
 #6 Exiv2::XmpParser::initialize at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/xmp.cpp:404
 #7 Exiv2::XmpParser::decode(Exiv2::XmpData&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/xmp.cpp:546
 #8 Exiv2::Internal::TiffDecoder::decodeXmp at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/tiffvisitor.cpp:408
 #9 Exiv2::Internal::TiffDirectory::doAccept at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/tiffcomposite.cpp:919

Comment 1 Francesco 2019-04-08 13:54:59 UTC
Created attachment 1553634 [details]
File: backtrace

Comment 2 Francesco 2019-04-08 13:55:00 UTC
Created attachment 1553635 [details]
File: cgroup

Comment 3 Francesco 2019-04-08 13:55:01 UTC
Created attachment 1553636 [details]
File: core_backtrace

Comment 4 Francesco 2019-04-08 13:55:02 UTC
Created attachment 1553637 [details]
File: cpuinfo

Comment 5 Francesco 2019-04-08 13:55:04 UTC
Created attachment 1553638 [details]
File: dso_list

Comment 6 Francesco 2019-04-08 13:55:05 UTC
Created attachment 1553639 [details]
File: environ

Comment 7 Francesco 2019-04-08 13:55:06 UTC
Created attachment 1553640 [details]
File: exploitable

Comment 8 Francesco 2019-04-08 13:55:07 UTC
Created attachment 1553641 [details]
File: limits

Comment 9 Francesco 2019-04-08 13:55:08 UTC
Created attachment 1553642 [details]
File: maps

Comment 10 Francesco 2019-04-08 13:55:10 UTC
Created attachment 1553643 [details]
File: mountinfo

Comment 11 Francesco 2019-04-08 13:55:11 UTC
Created attachment 1553644 [details]
File: open_fds

Comment 12 Francesco 2019-04-08 13:55:12 UTC
Created attachment 1553645 [details]
File: proc_pid_status

Comment 13 Francesco 2019-04-10 19:55:50 UTC
The only workaround is to kill tracker via:

tracker daemon -t

Otherwise it will flood the journal and fill the disk with coredumps.

Comment 14 kevin.v 2019-04-20 11:20:25 UTC
Hello,

I also have the issue on Fedora 29 Workstation. My computer has 4 hard disks/SSD (one is not readable by Fedora, which is normal ; the others are formated in ext4)

Comment 15 Ben Cotton 2019-10-31 19:35:23 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Ben Cotton 2019-11-27 22:01:22 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.