On Fri May 19, 2023 at 10:43 AM CEST, Robin Jarry wrote:
> There are several ways the ui message channel can fill up leading to
> deadlocks.
>
> 1) Invalidate() changes the value of uiState to DIRTY. The following
>    call sequence:
>
>       QueueRedraw()
>       Invalidate()
>       QueueRedraw()
>
>    Leads to multiple nil messages being queued in the message channel
>    whereas one could assume that the second QueueRedraw() would do
>    nothing. This is caused by the tri-state nature of uiState.

Thanks! It looks like this indeed fixes the issue I reported, I
didn't experience any dead-locks anymore thus far!

-- 
Maarten van Gompel

On Thu May 18, 2023 at 10:07 AM CEST, Robin Jarry wrote:
> Humm, this is probably another unrelated bug.
>
> When aerc is frozen again, could you dump the full trace as I explained
> before? Please don't send the dump in a separate file as attachment.
> This causes issues with sr.ht mail servers. Simply paste it inline.

Here is the new trace after applying this patch:

SIGQUIT: quit
PC=0x46efe1 m=0 sigcode=0

goroutine 82 [syscall]:
runtime.notetsleepg(0xffffffffffffffff?, 0xc000448f28?)

On Wed May 17, 2023 at 4:28 PM CEST, Tim Culverhouse wrote:
> On Wed May 17, 2023 at 9:16 AM CDT, Robin Jarry wrote:
> > To avoid multiple queued redraw events, merge ui.QueueRedraw() into
> > ui.Invalidate(). If there is no pending redraw, the ui will be marked as
> > DIRTY and a nil message will be queued.
> >
> > In the main event loop, only call ui.Render() when the processed message
> > is a nil message (redraw request).
> >
> > Signed-off-by: Robin Jarry <robin@jarry.cc>
> > ---
>
> Maarten - 
>

On Wed May 17, 2023 at 1:09 PM CEST, Robin Jarry wrote:
> Can you get a full (all goroutines) traceback when aerc is frozen? Here is the procedure:
>
> Start arec redirecting stderr to a file: aerc 2>trace.txt
>
> Wait for aerc to freeze and kill it from another terminal: killall -QUIT aerc 
>
> The traceback should be dumped in trace.txt by the go runtime before aerc is killed.

Sure! Here's the traceback (attached). I hope it provides some insight.

-- 
Maarten van Gompel

> Is this a split view or a message view tab?

Message view only (and sidebar on the left).

I also tried throwing away my entire aerc.conf btw
(https://git.sr.ht/~proycon/dotfiles/tree/master/item/aerc), but the
problem still reproduced. It's puzzling me now that not everybody's
experiencing this issue.

-- 
Maarten van Gompel

> Are there certain emails causing it to freeze? If so, could you send one
> to me (redacted if necessary).
> Does it freeze *every* time for certain things or just sometimes?

There isn't really an input trigger, no. It almost seems more
time-bound, as if the threads get in some kind of dead lock?
And yes, it freezes every time, sometimes I can still view the first message and
then on the second it fails, sometimes I can (within one or two seconds)
go through 3 or 4 messaes and then it fails.

I produced the following gdb backtrace by attaching to the running (yet
frozen) process but I don't think it's very informative (a sane process
looks similar if not identical):

On Tue May 16, 2023 at 10:53 PM CEST, Tim Culverhouse wrote:
> I saw from your initial email you are using bat. Does this happen if you
> use straight 'less'? trying to figure out how to reproduce the issue so
> I can debug.

Indeed, I just tried with less instead of bat, and the problem still reproduces
yes.

I also tried on the console instead of in a terminal in wayland and
there too it froze.

On Tue May 16, 2023 at 8:51 PM CEST, Robin Jarry wrote:
> Instead of reverting could you try before and after that commit?

Right, I just did that and I can confirm: this commit is indeed the issue.
All is fine before and the problem immediately shows on c7b122f4c4a87cd54402c78465e1a5c882f37aeb

On Tue May 16, 2023 at 8:45 PM CEST, Maarten van Gompel wrote:
> > I never saw this particular bug but I would assume it is caused by the new tcell-term version.
> >
> > https://git.sr.ht/~rjarry/aerc/commit/c7b122f4c4a87cd54402c78465e1a5c882f37aeb
> >
> > Tim, what is your take?
>
> I just reverted that commit but the problem still quickly reproduced
> without it, so I don't think it's the culprit.

Correction, I accidentally reverted a later commit with the same name (a
later upgrade), so your suspicion still stands..

--