Content-Type: multipart/mixed; boundary="===============0072518398448121060=="
MIME-Version: 1.0
To: Sebastian Spaeth <Sebastian@SSpaeth.de>,  notmuch@notmuchmail.org
From: Justus Winter <4winter@informatik.uni-hamburg.de>
In-Reply-To: <notmuch-sha1-f155d93e11888b35377531dd556b03fd493b7590>
References:
 <1318198374-926-1-git-send-email-4winter@informatik.uni-hamburg.de>
	<1318198374-926-2-git-send-email-4winter@informatik.uni-hamburg.de>
	<4eddf2b1.4288980a.0b74.5557@mx.google.com> <87fwgx7vmm.fsf@SSpaeth.de>
	<notmuch-sha1-f155d93e11888b35377531dd556b03fd493b7590>
Subject: Re: [PATCH 2/2] python: annotate all calls into libnotmuch with types
Date: Wed, 07 Dec 2011 19:49:31 +0100
Message-Id: <E1RYMYd-0003wu-Ea@thinkbox.jade-hamburg.de>
Precedence: list

--===============0072518398448121060==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Quoting Justus Winter (2011-12-06 13:51:08)
>Quoting Sebastian Spaeth (2011-12-06 13:05:53)
>>On Tue, 06 Dec 2011 10:46:31 +0000, Patrick Totzke <patricktotzke@googlem=
ail.com> wrote:
>>> This commit breaks raising XapianErrors for me.
>>> =

>>> If I lock the index with some `notmuch tag +test '*'`
>>> and try to write to it in alot, i get a segfault and
>>> the following on stderr:
>>> =

>>> Xapian exception occurred opening database: Unable to get write lock on
>>> /home/pazz/mail/.notmuch/xapian: already locked
>>
>>Hi Justus,
>>I can confirm that this patch breaks as Totzke has described it:
>>
>>http://git.notmuchmail.org/git/notmuch/commitdiff/3434d194026ff65217d9342=
ffe511f67fd71e79f
>>
>>This change makes python segfault with a Xapianerror on stdout rather
>>than the python exception that we were seeing before this patch.
>>
>>-     _open.restype =3D c_void_p
>>+     _open.restype =3D NotmuchDatabaseP
>>
>>
>>As the patch obviously fixed other crashers I would like to not revert
>>it. Can you have a look and see if you find a cause of that?
>
>Yes, I've seen that one as well and could not figure out what causes
>it since I thought that I wasn't changing the semantic of the binding.
>
>I began running alot in gdb since I get segfaults within libnotmuch
>from time to time and managed to get a stack trace pointing to
>notmuch_database_begin_atomic, but I couldn't figure out what caused
>it.

#0  0x00007f5f25e30f71 in notmuch_database_begin_atomic () from /home/teyth=
oon/.local/lib/libnotmuch.so.2
#1  0x00007f5f2605ef70 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dy=
nload/_ctypes.so
#2  0x00007f5f2605e9eb in ffi_call () from /usr/lib/python2.7/lib-dynload/_=
ctypes.so
#3  0x00007f5f260529c7 in _call_function_pointer (argcount=3D1, resmem=3D0x=
7fff57659500, restype=3D<optimized out>, =

    atypes=3D<optimized out>, avalues=3D0x7fff576594e0, pProc=3D0x7f5f25e30=
f70 <notmuch_database_begin_atomic>, =

    flags=3D4353) at /home/packages/python/2.7/python2.7-2.7.2/Modules/_cty=
pes/callproc.c:827

with stderr saying:

A Xapian exception occurred opening database: Unable to get write lock on /=
home/teythoon/Maildir/.notmuch/xapian: already locked

Justus

--===============0072518398448121060==
Content-Type: application/octet-stream
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=".signature"

bG92ZSB1IGFsb3QgQCxACgo=

--===============0072518398448121060==--