From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 8A6F66DE01D8 for ; Fri, 9 Nov 2018 06:56:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.104 X-Spam-Level: X-Spam-Status: No, score=0.104 tagged_above=-999 required=5 tests=[FROM_EXCESS_BASE64=0.105, SPF_PASS=-0.001] autolearn=disabled 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 yW-ZGHo4epeF for ; Fri, 9 Nov 2018 06:56:28 -0800 (PST) X-Greylist: delayed 432 seconds by postgrey-1.36 at arlo; Fri, 09 Nov 2018 06:56:28 PST Received: from praha.dcepelik.cz (praha.dcepelik.cz [185.8.165.213]) by arlo.cworth.org (Postfix) with ESMTP id 04DFD6DE018C for ; Fri, 9 Nov 2018 06:56:27 -0800 (PST) Received: from localhost (eduroam2-114.ms.mff.cuni.cz [195.113.17.114]) by praha.dcepelik.cz (Postfix) with ESMTPSA id AAB984A3F8 for ; Fri, 9 Nov 2018 15:49:13 +0100 (CET) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="===============0182090655009554859==" MIME-Version: 1.0 Content-Disposition: inline To: notmuch@notmuchmail.org Message-ID: <154177495352.5588.12072713055654441286@x1.localdomain> From: =?utf-8?b?RGF2aWQgxIxlcGVsw61r?= User-Agent: alot/0.7 Subject: segfault using python bindings Date: Fri, 09 Nov 2018 15:49:13 +0100 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: , X-List-Received-Date: Fri, 09 Nov 2018 14:56:30 -0000 --===============0182090655009554859== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Notmuch devs, I'm facing an issue trying to use the Python bindings. This trivial piece of code segfaults: import notmuch database =3D notmuch.Database() threads =3D database.create_query('tag:inbox and not tag:killed').searc= h_threads() = for t in threads: print("Thread:", t) msgs =3D t.get_toplevel_messages() for m in msgs: print("Message:", m) msgs =3D t.get_toplevel_messages() next(msgs) The problem is triggered by the call to next. Doing this instead works: database =3D notmuch.Database() threads =3D database.create_query('tag:inbox and not tag:killed').searc= h_threads() for t in threads: print("Thread:", t) msgs =3D t.get_toplevel_messages() for m in msgs: print("Message:", m) threads =3D database.create_query('tag:inbox and not tag:killed').searc= h_threads() for t in threads: print("Thread:", t) msgs =3D t.get_toplevel_messages() for m in msgs: print("Message:", m) It seems that the problem is caused by calling get_toplevel_messages twice on the same Threads object. I've been able to narrow the problem down using gdb. The first few frames of the stack-trace are: #0 0x000055555557da90 in () #1 0x00007ffff665db5a in Xapian::Document::Internal::get_value[abi:cxx= 11](unsigned int) const () at /usr/lib/libxapian.so.30 #2 0x00007ffff665db91 in Xapian::Document::get_value[abi:cxx11](unsign= ed int) const () at /usr/lib/libxapian.so.30 #3 0x00007ffff6e3165a in notmuch_message_get_header(notmuch_message_t*= , char const*) (message=3D0x5555556e6920, header=3D0x7ffff7195f78 "from") at lib/m= essage.cc:549 #4 0x00007ffff6efb1c8 in ffi_call_unix64 () at /usr/lib/libffi.so.6 The () seems to denote C++'s tuple class: (gdb) frame 0 #0 0x000055555557da90 in ?? () (gdb) lis 1 // -*- C++ -*- 2 = 3 // Copyright (C) 2007-2018 Free Software Foundation, Inc. 4 // 5 // This file is part of the GNU ISO C++ Library. This library is free 6 // software; you can redistribute it and/or modify it under the 7 // terms of the GNU General Public License as published by the 8 // Free Software Foundation; either version 3, or (at your option) 9 // any later version. 10 = Searching further, I've arrived at the following piece of Xapian code (xapian-core/backends/documentinternal.h): 390 std::string get_value(Xapian::valueno slot) const { 391 if (values) { 392 auto i =3D values->find(slot); 393 if (i !=3D values->end()) 394 return i->second; 395 return std::string(); 396 } 397 398 return fetch_value(slot); 399 } Since the invalid dereference indicates a tuple, I suspect the crash stems from the use `second' on line 394. (The (->) dereference likely does not cause the crash since otherwise we wouldn't arrive at the tuple.) When I use alot with this version of notmuch/python bindings, it works just fine, but I suspect that's because alot wraps all the provided objects to avoid this sort of bugs (and allow for repeated iteration over Threads objects, etc), and hence avoid calling get_toplevel_messages() twice. Does the problem lie with my fundamental misunderstanding of how the bindings work, or is this a bug? Linux x1 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x= 86_64 GNU/Linux Python 3.7.1 built from upstream @ 7f726c6 (AUR: notmuch-git 3:0.28.2.7.g7f726c6e-1) Regards, David --===============0182090655009554859== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Description: signature Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE1W8XnnLsjcC3H4ylq55LF2s9c50FAlvlnmYACgkQq55LF2s9 c51CBwf/Tkm6EenR46QKCjgfbpC9yK6/S/9CQRjrsFXGdPQDZRqiszpARabOO16f orflzuvmNkE7HomaS3U+fpFQiJs1HvSPFFM7uzl/39he9fofFJ8hfZXJZeVi9msg nApO3aV1ei5+4TWx27MxI52FpXiy5ggNhT0NhgtUh6IYHGC2rn2PqfS6NfCVcqZ+ pLU7Y68Vb9eSPXwRfG2hInmGFcut7KTSGJRJ7r1WG0XG2Kdvh2mX8uVgWtJsQdls jLKrKKfJyOq4SKKYifGBDZKgR/qJKllKIETiOmPVpVCwMUqGuo/wGXPcCj2KaAdw 8kVJfTGwsskQxJqoF0mLOdW1lIPOsQ== =9oon -----END PGP SIGNATURE----- --===============0182090655009554859==--