This post was not a bug report. As it says, the problem no longer
appears to be happening (though it's hard to prove a "never").
As I said in the report two years ago, which I provided a link to in my
post yesterday, I looked into it fairly extensively, including running
truss and looking at mutt source and various library sources. That
original post had a quite a bit of info, but not nearly as much as I had
gone into.
So I guess thanks for looking into it, but I wonder why.
-mm-
On Fri, Mar 21, 2025 at 01:56:06PM +0100, Matthias Apitz wrote:
> El día viernes, marzo 21, 2025 a las 11:43:15a. m. +0000, Nacho via
> Mutt-users escribió:
>
> > > I run for years mutt in FreeBSD, actual 2.2.12 in FreeBSD 14.0-CURRENT
> > > and in the terminal urxvt, all compiled from ports. I tested now:
> > >
> > > - start mutt, stay in index view
> > > - resized the urxvt
> > > - no lock
> >
> > Me too, have been using mutt in urxvt with FreeBSD for almost 9 years now,
> > many
> > different versions, resizing urxvt all the time since I use tilling WMs,
> > never
> > ever had a lock.
> >
> > Those locks may be related to other thing, not mutt, maybe perl scripts
> > running
> > in the terminal background (package urxvt-perls).
> >
>
> I investigated the situation with 'truss -p PID' (PID of mutt):
>
> When you resize the urxvt, perhaps triggered by the window manager, the
> process gets informed with a signal SIGWINCH "Window size change" and the
> default action is "discard signal", which means mutt is listening on this
> and rewrites the content, here of the index page, into the resized terminal:
>
> $ truss -p 1679
> ...
>
> poll({ 0/POLLIN },1,120000) ERR#4 'Interrupted system call'
> SIGNAL 28 (SIGWINCH) code=SI_KERNEL
> sigprocmask(SIG_SETMASK,{ SIGTSTP|SIGWINCH },0x0) = 0 (0x0)
> sigreturn(0x8211a6f80) EJUSTRETURN
> sigprocmask(SIG_SETMASK,{
> SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
> },{ }) = 0 (0x0)
> sigaction(SIGINT,{ 0x82bea0960 SA_RESTART|SA_SIGINFO ss_t },{ 0x82bea0960
> SA_SIGINFO ss_t }) = 0 (0x0)
> sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
> ioctl(0,TIOCGETA,0x8211a79f0) = 0 (0x0)
> write(1,"\^[[?25h",6) = 6 (0x6)
> write(1,"\^[[?25l",6) = 6 (0x6)
> openat(AT_FDCWD,"/dev/tty",O_RDONLY,00) = 5 (0x5)
> ioctl(5,TIOCGWINSZ,0x8211a7a88) = 0 (0x0)
> close(5) = 0 (0x0)
> write(1,"\^[[39;49m\^[[38;5;0m\^[[48;5;15"...,2495) = 2495 (0x9bf)
> write(1," gone \^[[6"...,1804) = 1804 (0x70c)
> sigprocmask(SIG_SETMASK,{
> SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
> },{ }) = 0 (0x0)
> sigaction(SIGINT,{ 0x82bea0960 SA_SIGINFO ss_t },{ 0x82bea0960
> SA_RESTART|SA_SIGINFO ss_t }) = 0 (0x0)
> sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
> poll({ 0/POLLIN },1,120000)
>
> I can at least iamgine that there could be an issue with this. But, I
> have never eved faced this in 20 years, or so. When the OP is able to
> reproduce this, such truss output would be good to see, perhaps with
> more flags directed to a file:
>
> $ truss -s 4096 -p PID
>
> Is the "lock" you face with a sleeping proc or looping proc?
>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
>
> Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023)
>
> I, Matthias, I am not at war with Russia.
> Я не воюю с Россией.
> Ich bin nicht im Krieg mit Russland.
--
Mark E. Mallett
