after a somewhat recent system upgrade (several weeks at least), the mutt mailer (an ncurses application) run in konsole occasionally produces garbled output. it *appears* that spurious linefeeds are inserted at somewhat random but stable positions (telling mutt to redraw the screen doesn't change a thing). i haven't been able to identify a pattern, other than the fact that today's system upgrade (which updated a bunch of libraries) made the problem much harder to reproduce. valgrind shows a few problems deep in qt (still 5.11.3; debian is being sluggish), but the screen corruption didn't appear in that run. the problem is not reproducible with xterm, rxvt, or gnome-terminal, so it must be either konsole itself, or how ncurses/terminfo uses it specifically. i realize that this isn't the most helpful report ever, but maybe it still rings a bell ...
Can you show screenshot with the problem and second one showing how it should look?
Created attachment 123010 [details] screenshot: mutt index there. i think it's obvious how it should look instead. ;) this is now actually 100% reproducible when starting konsole+mutt. but pressing ctrl-l (redraw) causes mutt to reconsider the index positions entirely, and the corruption disappears. valgrind still doesn't show anything beyond the problems deep in qt.
Created attachment 123011 [details] screenshot: mutt mail botched it gets crazier when i open your mail ...
Created attachment 123012 [details] screenshot: mutt mail ok ... and in this case returns to normal when pressing ctrl-l.
i also had the case in this mail display where the whole screen appeared to be scrolled up, so the top was missing, while the bottom was not repainted. in this case, pressing ctrl-l cleared the screen, but the vertical offset remained until changing the view. all this is (approximately) valgrind-clean.
it's *weird*: running mutt (instead of konsole) in valgrind makes the issue disappear. however, running mutt (without vg) inside "xterm -tn xterm-256color" (that's what $TERM is inside konsole here) with the same geometry does _not_ make it reproducible. so ... running under vg slows the output down, so maybe a race condition?
ok, this is clearly a bug in ncurses after all. i added logging code for the raw pty stream, and what mutt/ncurses is sending is just weird. cat'ing it in an xterm produces the same artifacts. it's still strange that running it in xterm in the first place does not trigger the problem, but whatever.
so, further investigation reveals that this *is* a konsole bug after all. it's a resurgence of bug #203185 introduced by commit b84c0f49a98cba53932c8bfc3c0a974983b14c1a (review trail at https://mail.kde.org/pipermail/konsole-devel/2016-April/025069.html which i'll refrain from commenting on for CoC reasons. i'll just suggest someone re-reads the documentation of qt signal delivery).
Git commit 2a6e520a7a92fe796add82f77cda922c54e091b9 by Oswald Buddenhagen. Committed on 12/12/2020 at 14:09. Pushed by ossi into branch 'master'. ensure that window size is correct before starting session (again) commit b84c0f49 replaced the previous hack, clearly failing to notice that in-thread qobject conections are direct by default. we need to make the competing connection queued instead. this remains a hack; a proper solution would be avoiding the instant resize by skipping the initialization to 80x25, but i'm not going to touch any of that mess. M +5 -3 src/session/Session.cpp https://invent.kde.org/utilities/konsole/commit/2a6e520a7a92fe796add82f77cda922c54e091b9