Dear Maintainer,

upon upgrading to bookworm, tracker-miner-fs, as started by user sessions,
became unusable, as it just crashes and restarts endlessly, filling logs
and, if enabled, filesystems with core dumps.
What I get in the logs is an endless stream of
[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 00007f9bf641bc18 sp 00007fff0ca38e10 error 4 in libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb

I tried to run tracker-miner-fs from a shell, in the foreground and with
full debugging, but then I get the message that it cannot be started because
the org.freedesktop.Tracker3.Miner.Files service is already allocated,
despite the fact that I killed the previously crashing/restarting process.
If there is anything I can do to help debug this, please tell me and I will
do it. I am filing this bug report on libtracker-sparql-3.0-0 because the
log entry says that's where the crash is occurring, but I don't know if that
is the real source of the problem.

Hell Mulas,
I tried to get to the source line of you dmesg output:


I think this relates to this source line:

https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

	g_critical ("Could not set up interface : %s",
		            error->message);


But a full backtrace is probably still needed by the maintainer.
You could probably collect one by installing systemd-coredump.
Then journalctl should contain a more detailed information on
which functions are involved.

Kind regards,
Bernhard