After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738450 - libtracker-data: Guard against failure to open the database
libtracker-data: Guard against failure to open the database
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: Store
0.16.x
Other All
: Normal normal
: ---
Assigned To: tracker-general
Depends on:
Blocks:
 
 
Reported: 2014-10-13 12:17 UTC by Debarshi Ray
Modified: 2014-10-13 14:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
libtracker-data: Guard against failure to open the database (1.20 KB, patch)
2014-10-13 12:19 UTC, Debarshi Ray
committed Details | Review
libtracker-data: Guard against invalid statements in public API (1.77 KB, patch)
2014-10-13 12:30 UTC, Debarshi Ray
committed Details | Review
libtracker-data: Be more explicit in the error message (1.73 KB, patch)
2014-10-13 13:48 UTC, Debarshi Ray
committed Details | Review

Description Debarshi Ray 2014-10-13 12:17:02 UTC
See this Fedora bug and its duplicates:
https://bugzilla.redhat.com/show_bug.cgi?id=972770

The session log from one of the dupes indicates that the tracker-store (PID 1373) failed to open the sqlite DB:
https://bugzilla.redhat.com/attachment.cgi?id=811418

That led to a bunch of assertions from prepare_for_exec in tracker-sparql-query.vala, and eventually a crash in tracker_db_statement_start_sparql_cursor because it does not check the validity of the incoming stmt.

We should guard against DBManager.get_db_interface failures, and verify the incoming stmt just to be sure.

This applies to master, tracker-1.2, tracker-1.0 and tracker-0.16
Comment 1 Debarshi Ray 2014-10-13 12:19:28 UTC
Created attachment 288381 [details] [review]
libtracker-data: Guard against failure to open the database
Comment 2 Debarshi Ray 2014-10-13 12:30:34 UTC
Created attachment 288382 [details] [review]
libtracker-data: Guard against invalid statements in public API

I don't know if the other tracker_db_manager_get_db_interface call sites can be expected to fail, but guarding against invalid TrackerDBStatements in non-private API seems like a good thing to anyway. Particularly since the tracker_db_statement_bind_* methods are already doing that.
Comment 3 Martyn Russell 2014-10-13 13:13:38 UTC
Hi Debarshi, thanks for the patches, both look good to me.
I've not really touched libtracker-data for a long while, mainly because it's the engine room and "just works" most of the time - but I would like to clean it up at some point (perhaps next cycle after all the latest changes that are going to cause enough disruption).
Comment 4 Debarshi Ray 2014-10-13 13:48:35 UTC
Created attachment 288385 [details] [review]
libtracker-data: Be more explicit in the error message
Comment 5 Martyn Russell 2014-10-13 14:01:46 UTC
Comment on attachment 288385 [details] [review]
libtracker-data: Be more explicit in the error message

Looks good to me.