Re: Python binding SIGABRT/SIGSEGV

[Floris Bruynooghe <flub@devork.be>]

On Thu 10 Feb 2022 at 13:16 +0100, Michael J Gruber wrote:

> Austin Lund venit, vidit, dixit 2022-02-10 06:56:12:
>> I'm clearly doing this python code wrong by not using the iterator correctly:
>> 
>> > import notmuch2
>> > 
>> > d = notmuch2.Database()
>> > m = list(d.messages("since:today"))
>> > p = m[0].path
>> > print(p)
>> 
>> But I seem to be getting a SIGABRT instead of a python stack trace.  Is
>> this the expected behaviour?
>
> You didn't expect it :)
>
> And this can be confusing. d.messages() returns an iterator through
> Message objects whose lifetime depends on the iterator. In contrast,
> thread.get_messages() returns on iterator through OwnedMessage objects
> whose lifetime depends on the thread.
>
> As soon as the iterator is depleted, the returned objects are (possibly)
> gone. (Well, because it's return by reference in Python, and ...)
>
> If you're interested in m[0] only you can "cheat" by not depleting the
> iterator:
>
> mm = next(d.messages("since:today"))
>
> p = mm.path
>
> This never frees the object (I think).
>
> My attempts with notmuch2._message.OwnedMessage (and db as parent)
> failed. There must be a better way, possibly using a context manager or
> search.
>
> I guess usually people just use the iterator in a for loop and do
> something with the message inside the loop (while the iterator is not
> depleted), such as converting it into a proper email.Message object
> (i.e. instantiating a new object from it).

Hum, to be fair I consider this a serious bug in the notmuch2 bindings.
You should not be able to crash whatever you do and not need to
understand the internal notmuch memory model.  I tried to build the
bindings so they would keep alive what they need, but it seems it fails
here.  It would be good to figure out if this can be fixed.

Cheers,
Floris