On 05/01/2021 11.55, Dave Howorth wrote:
On Tue, 5 Jan 2021 04:17:57 +0100 "Carlos E. R." <> wrote:
On the man page, it says:
"The actual extraction is done by a separate process. This is done to isolate the calling process from any memory leaks or crashes in the libraries Tracker uses to extract metadata."
So it seems that maybe your problems are caused by some library you have installed that is borked or not compatible with tracker? I don't use tracker and have no idea of what the logs show, but maybe it's worth trying to pin down the particular place the problem occurs.
To me it seems that they are aware that it crashes and do some
mitigation, instead of solving the problem.
I have no idea how to investigate whether there are wrong libraries
related to tracker.
cer@Telcontar:~> rpm -qa | grep tracker
tracker-debuginfo-2.3.2-lp152.2.4.x86_64
grilo-plugin-tracker-0.3.11-lp152.2.2.x86_64
tracker-miner-files-2.3.2-lp152.1.3.x86_64
libtracker-common-2_0-2.3.2-lp152.2.4.x86_64
tracker-miners-2.3.2-lp152.1.3.x86_64
tracker-2.3.2-lp152.2.4.x86_64
libtracker-sparql-2_0-0-2.3.2-lp152.2.4.x86_64
tracker-miners-debuginfo-2.3.2-lp152.1.3.x86_64
tracker-miners-lang-2.3.2-lp152.1.3.noarch
libtracker-control-2_0-0-2.3.2-lp152.2.4.x86_64
libtracker-common-2_0-debuginfo-2.3.2-lp152.2.4.x86_64
libtracker-miner-2_0-0-2.3.2-lp152.2.4.x86_64
tracker-debugsource-2.3.2-lp152.2.4.x86_64
libtracker-sparql-2_0-0-debuginfo-2.3.2-lp152.2.4.x86_64
libxatracker2-1.0.0-lp152.27.1.x86_64
libtracker-miner-2_0-0-debuginfo-2.3.2-lp152.2.4.x86_64
libfolks-tracker25-0.13.1-lp152.2.4.x86_64
tracker-miners-debugsource-2.3.2-lp152.1.3.x86_64
tracker-lang-2.3.2-lp152.2.4.noarch
All are leap 152 libraries.
I did a gdb backtrace of one of the crashes selected at random; I have
9605 crashes to choose from this minute. I can do more if somebody wants
them. Heck, I can trace hundreds of them if somebody tells me how to
automate the process. But the system will erase the backtraces
automatically via systemd-tmpfiles after some unknown number of days, so
there is a hurry.
Telcontar:~ # coredumpctl gdb 25653
PID: 25653 (tracker-extract)
...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib/tracker-extract'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 std::_Rb_tree const, std::__cxx11::basic_string warning: Source file is more recent than executable.
1187 { return _M_lower_bound(_M_begin(), _M_end(), __k); }
[Current thread is 1 (Thread 0x7feccb7fe700 (LWP 25669))]
(gdb) quit
Telcontar:~ #
--
Cheers / Saludos,
Carlos E. R.
(from 15.2 x86_64 at Telcontar)