Instead of setting a pointer, the pointer pointing to the pointer was
overwritten. As a result, e_book_backend_file_load_revision() always saw a
NULL pointer when opening the address book (regardless whether in
evolution-addressbook-factory or a DRA client) and used
e_book_backend_file_bump_revision() to write a new revision.
It is not entirely clear whether overwriting the wrong pointer (which was on
the stack and thus should not have been that important) or these concurrent
writes were to blame, but testing shows that this fix solves a mysterious
sqlite query failure ("corrupt database") in the DRA client when running
SyncEvolution's testpim.py TestContacts.testFilterStartupRefineSmart.
Fixes BGO #697173.
stmt = sqlite3_mprintf (
"SELECT revision FROM folders WHERE folder_id = %Q", folderid);
success = book_backend_sql_exec (
- ebsdb->priv->db, stmt, get_string_cb, &revision_out, error);
+ ebsdb->priv->db, stmt, get_string_cb, revision_out, error);
sqlite3_free (stmt);
UNLOCK_MUTEX (&ebsdb->priv->lock);