Hi Sebastian, Patrick. On Sat, 18 Jun 2011 12:30:01 +0200, Sebastian Spaeth <Sebastian@SSpaeth.de> wrote: > On Fri, 17 Jun 2011 17:10:24 +0100, Patrick Totzke : > > #0 0x006eb87d in Xapian::Document::Internal::get_value(unsigned int) const () from /usr/lib/sse2/libxapian.so.22 > > #1 0x006eb952 in Xapian::Document::get_value(unsigned int) const () from /usr/lib/sse2/libxapian.so.22 > > #2 0x00523963 in notmuch_message_get_date () from /usr/local/lib/libnotmuch.so.1 > > One question, what type is libnotmuch really returning here? The code: > > > time_t > notmuch_message_get_date (notmuch_message_t *message) > { ... > return Xapian::sortable_unserialise (value); > } > > But Xapian API says that sortable_unserialise() returns floating type "double" > > http://xapian.org/docs/apidoc/html/namespaceXapian.html#326fe2d6b0ee59ac9536f3960e8fd99b > "Convert a string encoded using sortable_serialise back to a floating > point number." > > But time_t is usually a (signed) long and not floating point. Obviously > things have worked just fine so far, but is libnotmuch really returning > the right type here? Sorry, I expose my total lack of basic C++ knowledge > here... > Converting double to time_t does not look good. Notmuch converts between time_t and double both when setting and getting the date. I guess it should work good in most cases at least. Perhaps Carl knows better that it is safe. This is not relevant to the segfault. The failure happens in: value = message->doc.get_value (NOTMUCH_VALUE_TIMESTAMP); before conversion from double to time_t. Sebastian, are you able to reproduce the issue? A python script that triggers the bug, perhaps? I would look at this if I can reproduce the problem. Patrick, can you install debugging symbols for libxapian and get the backtrace again? On Debian you need to install libxapian22-dbg. Regards, Dmitry > Sebastian > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch