summaryrefslogtreecommitdiff
path: root/bindings/python-cffi/notmuch2/_message.py
AgeCommit message (Collapse)Author
2020-06-16Make messages returned by Thread objects ownedFloris Bruynooghe
This reverses the logic of StandaloneMessage to instead create a OwnedMessage. Only the Thread class allows retrieving messages more then once so it can explicitly create such messages. The added test fails with SIGABRT without the fix for the message re-use in threads being present.
2020-06-16python/notmuch2: do not destroy messages owned by a queryAnton Khirnov
Any messages retrieved from a query - either directly via search_messages() or indirectly via thread objects - are owned by that query. Retrieving the same message (i.e. corresponding to the same message ID / database object) several times will always yield the same C object. The caller is allowed to destroy message objects owned by a query before the query itself - which can save memory for long-lived queries. However, that message must then never be retrieved again from that query. The python-notmuch2 bindings will currently destroy every message object in Message._destroy(), which will lead to an invalid free if the same message is then retrieved again. E.g. the following python program leads to libtalloc abort()ing: import notmuch2 db = notmuch2.Database(mode = notmuch2.Database.MODE.READ_ONLY) t = next(db.threads('*')) msgs = list(zip(t.toplevel(), t.toplevel())) msgs = list(zip(t.toplevel(), t.toplevel())) Fix this issue by creating a subclass of Message, which is used for "standalone" message which have to be freed by the caller. Message class is then used only for messages descended from a query, which do not need to be freed by the caller.
2019-12-24python/notmuch2: fix typo for "destroyed"Daniel Kahn Gillmor
Another fix to the docstrings, this time for the English part of the docstrings, not the Python class name. No functional changes here. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-03Rename package to notmuch2Floris Bruynooghe
This is based on a previous discussion on the list where this was more or less seen as the least-bad option.