Floris Bruynooghe <f...@devork.be> writes:

> Hi,
> I started writing some test cases to define better what you can do with
> a closed database and make sure that the python bindings do not behave
> unexpectedly here too.
> One of the first things I tried ends up with xapian calling
> exit_group(2) directly, terminating the process.  So I'm wondering if
> I'm approaching this entirely the wrong way.  My understanding is that
> we should generally be allowed to use anything after the database has
> been closed, as long as nothing has been destroyed.
> Below is a minimal reproducible example of what I'm testing so far.  I
> must admit I'm generally lazy here and usually just test with notmuch
> that is currently in Debian testing.

Funny that you should mention lazy, that's basically what the problem is
here ;). notmuch_message_get_message_id is lazily trying to read the
information from the database. This is a bit surprising here because of
the query, but that's not really visible once the message object is

In principle it could be documented what parts of the API can trigger
access to the database, but I'm not sure about the benefit of the extra
complexity. It might be safer to assume that only access to already
fetched information is safe. In particular if you move

    messageid = notmuch_message_get_message_id(msg);

before you close the database, then printing it out afterwards works. I
didn't run it valgrind to make sure, but afaik, that should be perfectly

The original motivation (see 7864350c938944276c1a378539da7670c211b9b5)
to allow long running processes to release the lock on the
database. This is not a pattern we use in the CLI, so it's not as well
tested as it could be. In particular the work to export
notmuch_database_reopen (tests, documentation) has not happened yet.


notmuch mailing list

Reply via email to