From: Floris Bruynooghe <flub@devork.be>
To: Patrick Totzke <patricktotzke@gmail.com>, notmuch@notmuchmail.org
Subject: Re: notmuch2 (python cffi bindings) segfault gdb logs
Date: Tue, 24 Nov 2020 22:31:00 +0100 [thread overview]
Message-ID: <871rgiqw6j.fsf@powell.devork.be> (raw)
In-Reply-To: <160612776000.3630981.17332396369796619495@piu>
Hi Patrick,
On Mon 23 Nov 2020 at 10:36 +0000, Patrick Totzke wrote:
> I've been complaining about the new (and old) python bindings causing the python interpreter to segfault occasionally. So far I was not able to reproduce this reliably nor provide error traces. This has just changed:
> see below and attached for what I got from gdb.
Your gdb info doesn't say explicitly (or I missed it), but this is
showing a SEGFAULT I guess?
> I hope that whoever is in charge of the bindings can make sense of
> it. I don't have any experience so far with cffi nor gdb and have a
> hard time debugging this. The logs below are my attempt to collect as
> much detail as possible about. Please let me know if I missed
> something.
From what I can tell we're calling a function to free something which
segfaults, so it probably was freed already and we didn't know. We need
to find out who freed it before and why we thought it still needed to be
freed.
> (gdb) info threads
> Id Target Id Frame
> * 1 Thread 0x7ffff7c0e740 (LWP 3614451) "python3" __GI_raise (sig=sig@entry=6)
> at ../sysdeps/unix/sysv/linux/raise.c:50
From this I gather we only have one thread, could you confirm this?
notmuch2 just isn't thread safe at the moment (I forget whether this was
intentional or by accident, might have been intentional depending on how
threadsafe libnotmuch is).
> Traceback (most recent call first):
> <built-in method notmuch_thread_destroy of CompiledLib object at remote 0x7ffff636f040>
> File "/home/pazz/.local/lib/python3.8/site-packages/notmuch2/_thread.py", line 38, in _destroy
> capi.lib.notmuch_thread_destroy(self._thread_p)
> File "/home/pazz/.local/lib/python3.8/site-packages/notmuch2/_thread.py", line 34, in __del__
> self._destroy()
> File "/home/pazz/projects/alot/alot/db/manager.py", line 570, in get_threads
> <built-in method next of module object at remote 0x7ffff78b70e0>
I pulled alot master and this does not match at all. Could you tell me
which git ref this was using so I can try and see what alot is actually
doing? (or some other way of sharing the source in this backtrace)
Cheers,
Floris
next prev parent reply other threads:[~2020-11-24 21:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-23 10:36 notmuch2 (python cffi bindings) segfault gdb logs Patrick Totzke
2020-11-24 21:31 ` Floris Bruynooghe [this message]
2020-11-25 10:35 ` Patrick Totzke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871rgiqw6j.fsf@powell.devork.be \
--to=flub@devork.be \
--cc=notmuch@notmuchmail.org \
--cc=patricktotzke@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).