The program aborts upon hitting page_down, after toggling tags on an item several times #1504
Comments
|
I just reproduced the issue by only hitting s, so I suppose this could be a dupe of #1460 after all. At least we have a fast reproducer here! |
|
Thanks for this. I can reproduce it as initially reported, but not just with the |
|
I'll try to look into it, but no promises. I was actually hoping you could answer those questions, which I asked in #1460 since you commented on the RFC for the FFI bindings. The bindings were renamed into
|
|
Got the following output for the first time while using the same reproducer above: |
|
Also got a stacktrace in the debug log, this time! It doesn't throw the same error, but it shows that not all exceptions are caught properly. |
|
I was hitting a segfault all the time with the same backtrace, using 424669b. I have now updated to 486df70, using python3-notmuch2 from ubuntu 20.10. I get much less segfault, but I can reliably get a segfault with the steps to reproduce of that issue. This time, the stack trace is a little different (though similar): You can find the full stack trace here (also with a version form The end of my log file looks like this (having replaced names and email addresses): |
|
Could you relay that to the notmuch list? Ideally as answer to my last mail on the python bindings segfaulting?
Many thanks,
P
Quoting Guillaume Emont (2021-03-02 17:44:41)
… I was hitting a segfault all the time with the same backtrace, using 424669b. I
have now updated to 486df70, using python3-notmuch2 from ubuntu 20.10. I get
much less segfault, but I can reliably get a segfault with the steps to
reproduce of that issue. This time, the stack trace is a little different
(though similar):
#0 __GI_raise ***@***.***=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x00007efcb2964864 in __GI_abort () at abort.c:79
#2 0x00007efcb074f4de in talloc_abort (reason=0x7efcb0759070 "Bad talloc magic value - unknown value") at ../../talloc.c:505
#3 0x00007efcb074f4d7 in talloc_abort_unknown_value () at ../../talloc.c:534
#4 talloc_chunk_from_ptr (ptr=0x375cc70) at ../../talloc.c:534
#5 _talloc_free (ptr=0x375cc70, location=<optimized out>) at ../../talloc.c:1767
#6 0x00007efcb09a9475 in _cffi_f_notmuch_thread_destroy (self=<optimized out>, arg0=<optimized out>) at build/temp.linux-x86_64-3.8/notmuch2._capi.c:4855
#7 0x000000000051dbff in cfunction_vectorcall_O (func=<built-in method notmuch_thread_destroy of _cffi_backend.Lib object at remote 0x7efcb09deb80>, args=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>)
at ../Objects/methodobject.c:482
#8 0x000000000050e7af in _PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=0x7efcaf48fec0, callable=<built-in method notmuch_thread_destroy of _cffi_backend.Lib object at remote 0x7efcb09deb80>)
at ../Include/cpython/abstract.h:127
#9 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=0x2332980) at ../Python/ceval.c:4963
#10 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:3469
#11 0x000000000051ede7 in PyEval_EvalFrameEx
(throwflag=0, f=Frame 0x7efcaf48fd40, for file /usr/lib/python3/dist-packages/notmuch2/_thread.py, line 38, in _destroy (self=<Thread(_parent=<ThreadIter(_db=<Database(mode=<Mode(_value_=0, _name_='READ_ONLY', __objclass__=<EnumMeta(_generate_next_value_=<function at remote 0x7efcb270e8b0>, __module__='notmuch2._database', __doc__='An enumeration.', _member_names_=['READ_ONLY', 'READ_WRITE'], _member_map_={'READ_ONLY': <...>, 'READ_WRITE': <Mode(_value_=1, _name_='READ_WRITE', __objclass__=<...>) at remote 0x7efcafeba040>}, _member_type_=<type at remote 0x8d2440>, _value2member_map_={0: <...>, 1: <...>}, READ_ONLY=<...>, READ_WRITE=<...>, __new__=<function at remote 0x7efcb270e820>) at remote 0x27541d0>) at remote 0x7efcb09ecd00>, _memptr__db_p_2756640=<_cffi_backend._CDataBase at remote 0x7efcaeffd630>, closed=False) at remote 0x7efcaeffd8e0>, _parent=<Query(_db=<...>, _memptr__query_p_2753770=<_cffi_backend._CDataBase at remote 0x7efcaeffd9c0>) at remote 0x7efcaeffd0d0>, _memptr__iter_p_2745350=<_cffi_backend._CDataBase at...(truncated)) at ../Python/ceval.c:741
#12 function_code_fastcall (globals=<optimized out>, nargs=1, args=<optimized out>, co=<optimized out>) at ../Objects/call.c:283
#13 _PyFunction_Vectorcall (func=<optimized out>, stack=0x7efcaf48fd18, nargsf=<optimized out>, kwnames=<optimized out>) at ../Objects/call.c:410
#14 0x0000000000509abc in _PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=0x7efcaf48fd18, callable=<function at remote 0x7efcafed0a60>) at ../Include/cpython/abstract.h:127
You can find the full stack trace here (also with a version form bt full).
The end of my log file looks like this (having replaced names and email
addresses):
DEBUG:manager:write-out item: ('toggle', <function TagCommand.apply.<locals>.refresh at 0x7fa91e46a040>, '(tag:inbox AND NOT tag:killed) AND thread:0000000000026cd1', ['unread'])
DEBUG:manager:cmd created
DEBUG:manager:got write lock
DEBUG:manager:got atomic
DEBUG:manager:ended atomic
DEBUG:manager:closed db
DEBUG:manager:<function TagCommand.apply.<locals>.refresh at 0x7fa91e46a040>
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:manager:called callback
DEBUG:manager:flush finished
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
DEBUG:globals:flush complete
DEBUG:ui:Got key (['page down'], [27, 91, 54, 126])
DEBUG:ui:cmdline: 'move page down'
DEBUG:ui:search command string: "move page down"
DEBUG:__init__:mode:search got commandline "move page down"
DEBUG:__init__:ARGS: ['move', 'page', 'down']
DEBUG:__init__:cmd parms {'movement': ['page', 'down']}
DEBUG:search:page down
DEBUG:utils:unquoted header: |Anne O'nymous ***@***.***>|
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.*
|
paretje
added a commit
to paretje/dotfiles
that referenced
this issue
Mar 19, 2021
After changing a couple of tags, changing the results of the current search buffer, I get a segfault. (Issue pazz/alot#1504). I had a look, and there doesn't seem to be a double free on the Python end, but I have yet to try if I can reproduce this in C by opening a database, starting a search, load a messages, open the database a second time, change the tag of that message, write and close the second database, destroy the message fetched from the first, and repeat this a couple of times. Anyway, I still can prevent this segfault by letting the query free the memory of it's threads, instead of destroying the thread once the Python object gets destructed.
|
Hi! I am also affected by this. I confirm that adding the workaround above in hooks.py prevents |
|
Is this on the latest release or alot from git master?
Quoting Cédric Boutillier (2021-11-08 09:02:34)
… Hi! I am also affected by this. I confirm that adding the workaround above in
hooks.py prevents alot from aborting after a few tags switchings.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android. *
|
|
This is 0.10 (the 0.10-1 package, from Debian unstable). |
|
Yes :)
Quoting Cédric Boutillier (2021-11-08 13:15:30)
… This is 0.10 (the 0.10-1 package, from Debian unstable).
Oh! I have just seen the commit on top of master from last month. That should
also probably fix that issue, shouldn't it?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android. *
|
|
With the latest commit, I cannot reproduce the issue anymore, even without the workaround above. But it is true, as its description says, that it slows down a little the program, noticeably at startup. Thanks for the indication! |
paretje
added a commit
to paretje/dotfiles
that referenced
this issue
Mar 2, 2022
It seems pazz/alot#1504 has been fixed with recent versions of notmuch.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I originally thought this issue I'm hitting was #1460, but since the following reproducer is so different from the one in #1460, which I cannot reproduce, I'm reporting details here.
Describe the bug
alotcrashes with signalABORT.Software Versions
master, 1e66a3d)Archlinux.
To Reproduce
Steps to reproduce the behaviour:
search tag:inboxThe crash doesn't occur with j or page-up.
But it does occur if you hit ctrl+d twice.
Error Log
alot.log
Full stacktrace, excerpt below:
The text was updated successfully, but these errors were encountered: