Eindhoven, the Netherlands
See my homepage at https://proycon.anaproy.nl for further details and contact info.
From Maarten van Gompel to ~rjarry/aerc-devel
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.
From Maarten van Gompel to ~rjarry/aerc-devel
Thanks! It looks like this indeed fixes the issue I reported, I didn't experience any dead-locks anymore thus far! -- Maarten van Gompel
From Maarten van Gompel to ~rjarry/aerc-devel
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?)
From Maarten van Gompel to ~rjarry/aerc-devel
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 - >
From Maarten van Gompel to ~rjarry/aerc-discuss
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
From Maarten van Gompel to ~rjarry/aerc-discuss
> 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
From Maarten van Gompel to ~rjarry/aerc-discuss
> 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):
From Maarten van Gompel to ~rjarry/aerc-discuss
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.
From Maarten van Gompel to ~rjarry/aerc-discuss
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
From Maarten van Gompel to ~rjarry/aerc-discuss
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.. --