At 18:00 -0700 07 Sep 2021, "Kevin J. McCarthy" <ke...@8t8.us> wrote:
On Tue, Sep 07, 2021 at 07:15:16PM -0400, Aaron Schrab wrote:Since updating from a build based on bcdb61560 (Add %T status format for $sort_thread_groups., 2021-08-05) to one based on 27e61da56 (Merge branch 'stable', 2021-08-24) I've been experiencing some sporadic crashes.Unfortunately both IMAP and thread code *have* been touched recently.
I'd thought that most of the thread changes were in the clear, at least until I'd looked further into my builds for writing the original message.
So it looks like I goofed something up. :-(
Trying to catch those types of issues is one of the reasons I try to follow master (or in some cases branches that aren't even that ready) fairly closely.
However, bcdb61560 isn't on master. Were you running off of my development branch before, or were you perhaps referring to 5aa75ed2?
Yes, I had been using your branch with the early support for $sort_thread_groups. I *thought* that I'd updated to the version of that that got into master, but apparently I hadn't. At least that early version of the new threading mode had seemed very stable to me. Of course with the sporadic nature of the crashes it's possible that I just hadn't hit the problem then.
You may also want to try enabling ASAN via something like export CFLAGS='-g3 -fno-omit-frame-pointer -fsanitize=address' and re-configure/recompile, to see if it can give an earlier warning about memory corruption.
I've added that to my configure wrapper script, and I'll be restarting to use the copy built with that as soon as I send this message.
For the more troublesome one I get the following backtrace. Once this comes up it will keep crashing when I attempt to change to the same folder, at least in the short term. Although if I open this folder once with the old build then switch back to the new build the problem will go away for awhile.Are you using $imap_qresync or $imap_condstore?
Yes, I have both of those enabled (using dovecot 2.3.16 from Debian unstable as the IMAP server). In at least some of the crashes I believe I've seen messages about QRESYNC failing immediately before; but I generally have mutt running in a tmux window that's set to close when mutt exits so the message is generally only visible very briefly.
The stack is in a pretty benign section, so it seems like it's a wild pointer or something corrupting memory.The other problem seems to occur on line 431 of thread.c: →· !tmp->fake_thread &&→·→· /* don't match pseudo threads */I usually test with $strict_threads enabled. I'll turn that off and see if I can trigger the problem.
If I run into a case where the problem seems to be at least briefly reproducible I'll try turning that off to see if that avoids the problem.
signature.asc
Description: PGP signature
