From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id kOqkHC7D+F4dSgAA0tVLHw (envelope-from ) for ; Sun, 28 Jun 2020 16:19:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id gDS/GC7D+F5URgAAB5/wlQ (envelope-from ) for ; Sun, 28 Jun 2020 16:19:58 +0000 Received: from arlo.cworth.org (arlo.cworth.org [50.126.95.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8E16A940145 for ; Sun, 28 Jun 2020 16:19:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 699676DE13AE; Sun, 28 Jun 2020 09:19:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj5lsP-qpaGY; Sun, 28 Jun 2020 09:19:50 -0700 (PDT) Received: from arlo.cworth.org (localhost [IPv6:::1]) by arlo.cworth.org (Postfix) with ESMTP id 6A3B86DE0F54; Sun, 28 Jun 2020 09:19:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id D5B986DE0F54 for ; Sun, 28 Jun 2020 09:19:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHAiGYCNVQP8 for ; Sun, 28 Jun 2020 09:19:47 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTP id CD8446DE024E for ; Sun, 28 Jun 2020 09:19:47 -0700 (PDT) Received: by fethera.tethera.net (Postfix, from userid 1001) id 4DAC161417; Sun, 28 Jun 2020 12:19:47 -0400 (EDT) Received: (nullmailer pid 1919912 invoked by uid 1000); Sun, 28 Jun 2020 16:19:45 -0000 From: David Bremner To: Floris Bruynooghe , notmuch@notmuchmail.org Subject: Re: Usage after database close In-Reply-To: <87d05je1j6.fsf@powell.devork.be> References: <87d05je1j6.fsf@powell.devork.be> Date: Sun, 28 Jun 2020 13:19:45 -0300 Message-ID: <87d05jkvry.fsf@tethera.net> MIME-Version: 1.0 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: notmuch-bounces@notmuchmail.org Sender: "notmuch" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 50.126.95.6 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: -1.01 X-TUID: kPXANIKElhiT Floris Bruynooghe 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 created. 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 legal. 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. d