thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2Fstretch 2017-03-19T12:36:51Z 2017-03-19T12:36:51Z Tomi Ollila tomi.ollila@iki.fi 2017-03-17T22:28:48Z urn:sha1:930920d5106e01d511dc339171ec3254e3d8771e The object where pointer to `data` was received was deleted before it was used in _notmuch_string_list_append(). Relevant Coverity messages follow: 3: extract Assigning: data = std::__cxx11::string(message->doc.()).c_str(), which extracts wrapped state from temporary of type std::__cxx11::string. 4: dtor_free The internal representation of temporary of type std::__cxx11::string is freed by its destructor. 5: use after free: Wrapper object use after free (WRAPPER_ESCAPE) Using internal representation of destroyed object local data. (cherry picked from commit 06adc276682d1d5f73d78df2e898ad4191eb4499) 2017-02-22T10:28:03Z David Bremner david@tethera.net 2017-02-22T10:17:47Z urn:sha1:4e649d000b9d3764aea98cb0e1120947d7f76f3d The two g_hash_table functions (insert, add) have different behaviour with respect to existing keys. g_hash_table_insert frees the new key, while g_hash_table_add (which is really g_hash_table_replace in disguise) frees the existing key. With this change 'ref' is live until the end of the function (assuming single-threaded access to 'hash'). We can't guarantee it will continue to be live in the future (i.e. there may be a future key duplication) so we copy it with the allocation context passed to parse_references (in practice this is the notmuch_message_t object whose parents we are finding). Thanks to Tomi for the simpler approach to the problem based on reading the fine glib manual. 2016-10-07T01:46:01Z David Bremner david@tethera.net 2016-10-05T01:12:56Z urn:sha1:b2d6f07a028a443c2f96e1684be5ec3addb55d96 The API was already documented, but for future readers note when the functions were added, 2016-10-07T01:45:46Z David Bremner david@tethera.net 2016-10-05T00:35:23Z urn:sha1:af8903df34647d9456e8f3fe26a164959969b451 It seems that no-one tried to compile without Xapian compact support since March of 2015, since that's when I introduced a syntax error in that branch of the ifdef. Given the choice of maintaining this underused branch of code, or bumping the Xapian dependency to a version from 2011, it seems reasonable to do the latter. 2016-10-02T01:19:07Z David Bremner david@tethera.net 2016-10-02T01:11:56Z urn:sha1:c2e74662bbbbf9be1fde0ae416dc2664ba3da3cd This should not change the SONAME, and therefore won't change the dynamic linking behaviour, but it may help some users debug missing symbols in case their libnotmuch is too old. 2016-09-28T11:14:08Z Tomi Ollila tomi.ollila@iki.fi 2016-09-27T15:06:52Z urn:sha1:1c3a8e0898be614b5183f0ae626386f7746e7e07 Found by gcc 6.1.1 -Wmisleading-indentation option (set by -Wall). 2016-09-24T13:08:45Z David Bremner david@tethera.net 2016-09-23T09:33:19Z urn:sha1:514a0a6a3bd74c03db6cd9b28edc0a29a8a2441e This is needed so that when the map is modified during traversal, and thus unlinked by the database code, the map is not disposed of until the iterator is done with it. 2016-09-21T21:14:25Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-07-08T09:15:36Z urn:sha1:693ca8d8a80438ce1e361e7e6d22288f52a11c55 We want to be able to query the properties directly, like: notmuch count property:foo=bar which should return a count of messages where the property with key "foo" has value equal to "bar". 2016-09-21T21:14:25Z David Bremner david@tethera.net 2016-06-13T01:05:52Z urn:sha1:58fe8fce1d1b7b86b4914a5a476ff21411c84082 This is a thin wrapper around the string map iterator API just introduced. 2016-09-21T21:14:24Z David Bremner david@tethera.net 2016-06-13T01:05:51Z urn:sha1:b846bdb48233c907d1ecaff495fbf6bc578910d6 Support for prefix based iterators is perhaps overengineering, but I wanted to mimic the existing database_config API.