GNOME Bugzilla – Bug 756869
tracker-miner-fs: Don't abort in tracker_file_notifier_init due to tracker_sparql_connection_get failure
Last modified: 2015-10-21 14:47:35 UTC
I am seeing a couple of downstream reports where the code hits the assertion in tracker_file_notifier_init and aborts with: 'Tracker-CRITICAL **: Could not get SPARQL connection: The connection is closed' I am beginning to think that we should try to handle this failure because the circumstances look similar to those in bug 755805 That bug was primarily triggered by the QA guys starting gdm, doing some screen recording, and then shutting it down again. When the gdm session was shut down, the DBus daemon was lost and creating a GDBusProxy for gvfs' remote volume monitors failed with: 'The connection is closed (g-io-error-quark, 18)' Interestingly, the gvfs bug led to tracker-extract crashes in the 99% of cases, even though I did see a libreoffice and mate-panel crash too. I guess, screen shooting the gdm session tickled tracker's miners. Anyway, my point is that it is not unreasonable to expect tracker to be robust against such situations.
Created attachment 313753 [details] [review] libtracker-miner: Handle failure to get a TrackerSparqlConnection
I don't know how to test this. I tried removing the executable bit from the tracker-store binary, killing all the tracker process and then doing 'tracker daemon -s', but that didn't hit this code path.
From #tracker on GIMPNet: 14:50 <garnacho_> rishi: just missing another check on sparql_contents_query_start() for paranoia IMO :)
Created attachment 313758 [details] [review] libtracker-miner: Handle failure to get a TrackerSparqlConnection
Comment on attachment 313758 [details] [review] libtracker-miner: Handle failure to get a TrackerSparqlConnection Looks good, thanks :)
Pushed all the way down to tracker-1.2.