David Bremner writes: > I've been attempting to port nmweb to the new bindings, but I got stuck > on a bug that segfaults python. I attached a reduced version that > reproduces the problem for me. It uses recent messages from the notmuch > list; it others can't reproduce let me know and I will try to make > something more self contained including a message set. > Attached is a slightly simpler (and more informative) reproducer It produces the the following output for me 7f23164b6cd0 87fsqijx7u.fsf@metapensiero.it 7f23164b6a90 87lf0anoiv.fsf@tethera.net 7f23164b6910 87bl16jezh.fsf@metapensiero.it 7f23164c3070 87bl0vlbys.fsf@powell.devork.be 7f23164c30d0 87lf0anoiv.fsf@tethera.net 7f23164b68e0 87bl16jezh.fsf@metapensiero.it 7f23164b6a00 87bl0vlbys.fsf@powell.devork.be zsh: IOT instruction python3 test.py The IOT instruction is actually talloc aborting. If I leave in the call to msg.header, it segfaults as before. I noticed that the message struct 0x139b8e0 is visited twice, once as part of the thread and once as part of reply-to-reply-to-reply. I think the issue here is that bindings destroy the iterator for replies, but the library docs say " * The returned list will be destroyed when the thread is * destroyed. " Perhaps that needs to be worded more strongly, to forbid the user from calling notmuch_messages_destroy. I still need to untangle the intended ownership semantics to be sure.