Re: Python binding SIGABRT/SIGSEGV

Subject: Re: Python binding SIGABRT/SIGSEGV

Date: Fri, 11 Feb 2022 11:41:23 +0200

To: Michael J Gruber, Austin Lund, notmuch@notmuchmail.org

Cc:

From: Tomi Ollila


On Fri, Feb 11 2022, Michael J. Gruber wrote:

> Austin Lund venit, vidit, dixit 2022-02-10 23:21:58:
>> On Thu, Feb 10, 2022 at 01:12:47PM +0100, Michael J Gruber wrote:
>> > Austin Lund venit, vidit, dixit 2022-02-10 06:56:12:
>> > > I'm clearly doing this python code wrong by not using the iterator correctly:
>> > > 
>> > > > import notmuch2
>> > > > 
>> > > > d = notmuch2.Database()
>> > > > m = list(d.messages("since:today"))
>> > > > p = m[0].path
>> > > > print(p)
>> > > 
>> > > But I seem to be getting a SIGABRT instead of a python stack trace.  Is
>> > > this the expected behaviour?
>> > 
>> > You didn't expect it :)
>> > 
>> > And this can be confusing. d.messages() returns an iterator through
>> > Message objects whose lifetime depends on the iterator. In contrast,
>> > thread.get_messages() returns on iterator through OwnedMessage objects
>> > whose lifetime depends on the thread.
>> 
>> I guess I didn't say it explicitly, but I would 'expect' the python
>> interpreter to raise an exception rather than having an unhandled
>> exception terminate the program.  Perhaps raising a MemoryError or
>> ReferenceError or some other exception would be better than an unhandled
>> SIGABRT.
>> 
>
> In fact you did. Sorry for overlooking this. (I still find db.messages()
> vs thread.get_messages() confusing.)
>
> The way memory handling works, one could even expect a more specific
> notmuch2.ObjectDestroyedError.
>
> As for the SIGABRT: I guess this is what "python -X faulthandler" is
> for, especially in the context of C extension modules:
>
> LANG=C python -X faulthandler t.py
> Fatal Python error: Aborted
>
> Current thread 0x00007f5bf667e740 (most recent call first):
>   File "/usr/lib64/python3.10/site-packages/notmuch2/_message.py", line
> 131 in path
>   File "/tmp/t.py", line 5 in <module>
>
> Extension modules: _cffi_backend (total: 1)
> Abgebrochen (Speicherabzug geschrieben)
>
> (Yes, it disrespects LANG)

You'd probably need LC_ALL=C for "overwriting" whatever in other LC_*
variables has been set. IIRC LANG just set default in case particular
LC_* is not set

Unfortunately this does not help solving SIGABRT case...

Tomi

>
> Line 131 is
>
> ret = capi.lib.notmuch_message_get_filename(self._msg_p)
>
> in the path method, and since _msg_p is a base.MemoryPointer() I would
> have hoped (now) to get a notmuch2.ObjectDestroyedError. Maybe _msg_p is
> destroyed but the Message object is not? Fishing in the dark here ...
>
> Michael
>
> P.S.: Sorry for the repeated message. I had problems with list bounces
> in the past, then remembered the original alias wrong, then replied to
> the reply to the wrong (only off-list-delivered) post. git@grubix.eu is
> the one subscribed to the list. I'll remember now.
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Thread: