[geary/geary-0.11] Fix crash in progress meter when populating search table. Bug 776383.

[Michael Gratton <mjog src gnome org>]

commit 7d83a89e9d1c2c16c487ed4a758c0700174eaf19
Author: Michael James Gratton <mike vee net>
Date:   Fri Jan 13 16:08:09 2017 +1100

    Fix crash in progress meter when populating search table. Bug 776383.
    
    * src/engine/imap-db/imap-db-account.vala
      (Account::populate_search_table_batch_async): total_unindexed was wildy
      inaccurate, since there may be been messages missing from MessageTable,
      MessageSearchTable, or both. When clamped to 0, but when there actually
      were messages to index, this would trigger an assert in the search
      progress meter. So for now instead use something wildly overinflated
      but guaranteed to not trigger the assert.

 src/engine/imap-db/imap-db-account.vala |   14 ++++++++------
 1 files changed, 8 insertions(+), 6 deletions(-)
---
diff --git a/src/engine/imap-db/imap-db-account.vala b/src/engine/imap-db/imap-db-account.vala
index 38741c1..49ecd57 100644
--- a/src/engine/imap-db/imap-db-account.vala
+++ b/src/engine/imap-db/imap-db-account.vala
@@ -1604,12 +1604,14 @@ private class Geary.ImapDB.Account : BaseObject {
             stmt.bind_uint(0, Geary.ImapDB.Folder.REQUIRED_FTS_FIELDS);
             stmt.bind_uint(1, Geary.ImapDB.Folder.REQUIRED_FTS_FIELDS);
             Gee.HashSet<int64?> message_ids = do_build_rowid_set(stmt.exec(cancellable), cancellable);
-            
-            // guesstimate at the number that need to be indexed ... technically if this is zero then
-            // we're done, but for safety allow the chaffing to go through, in case there are search
-            // rows that do not correspond to message rows (which is bad but not fatal)
-            total_unindexed = (message_ids.size - search_ids.size).clamp(0, int.MAX);
-            
+
+            // This is hard to calculate correctly without doing a
+            // join (which we should above, but is currently too
+            // slow), and if we do get it wrong the progress monitor
+            // will crash and burn, so just something too big to fail
+            // for now. See Bug 776383.
+            total_unindexed = message_ids.size;
+
             // chaff out any MessageTable entries not present in the MessageSearchTable ... since
             // we're given a limit, stuff messages req'ing search into separate set and stop when limit
             // reached