GNOME Bugzilla – Bug 791243
random crash (SIGSEGV)
Last modified: 2021-05-26 22:24:30 UTC
Created attachment 365000 [details] gdb backtrace of the crash I got a random crash (SIGSEGV) in tracker. I am using tracker 2.0.2-1, sqlite 3.21.0-1 and GNOME 3.26 on Debian buster. If the below gdb backtrace and the attached full gdb backtrace isn't useful, please close this bug. Core was generated by `/usr/lib/tracker/tracker-store'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 238220
Created attachment 365891 [details] gdb backtrace of the crash I got what looks like the same crash again. Core was generated by `/usr/lib/tracker/tracker-store'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 238281
Seeing that the deepest 3/4ths of the backtrace belongs to SQLite, and the deepmost function still belonging to Tracker code is just creating a SQL statement, all my bets are on this being a SQLite bug.
I've posted a message the sqlite-users mailing list, it should show up there after moderation.
The thread is available here: https://marc.info/?i=1513989092.2859.79.camel@bonedaddy.net The sqlite folks suggested it might be a heap corruption issue in tracker-store and said they would investigate further. https://marc.info/?i=CALwJ=MzGRs_SL8+5eDVXw0ZB=4TGEeU-3eFu+6+x9OeSa6cMUA@mail.gmail.com
Thanks for moving the bug around :). The heap corruption scenario sounds plausible, but there's been no other recent reports of tracker-store crashes, and your SQLite seems bleeding edge enough. I'll be doing some runs on valgrind anyway, maybe you can do some too with: killall -9 tracker-store ; valgrind --leak-check=full --num-callers=30 --log-file=$(non_indexed_dir)/valgrind-log $(libexecdir)/tracker-store (replace non_indexed_dir and libexecdir with suitable locations) One thing that looks mildly odd in the backtrace is that tracker-store is dispatching a SELECT query. This is not wrong per-se, but for performance reasons non-update queries are usually performed directly by the users of libtracker-sparql through a readonly connection, instead of through dbus/tracker-store. This may indicate tracker-store and client(s) are running with different locales, or that TRACKER_SPARQL_BACKEND=bus is somewhere in the environment? Still, this shouldn't influence nor cause crashes.
Oh, but the GtkFileChooser search is done through direct dbus calls, that might a reason.
Created attachment 365900 [details] valgrind log I did a valgrind run and it just sat there for hours, when I eventually hit Ctrl+C I noticed that the valgrind log file had quite a lot of data in it.
Thanks. I see some minor leaks, and the usual noise from glib/libc creating caches that don't get ever freed until process exit. But there seems to be no reports of "Invalid read" or "Invalid write", which is what I would expect in memory corruption or mishandling scenarios. And it's kind of the same here...
Created attachment 368394 [details] gdb backtrace of another crash I got another similar (but slightly different) crash: Core was generated by `/usr/lib/tracker/tracker-store'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 238398
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/tracker/-/issues/ Thank you for your understanding and your help.