Re: [Mutt] #2194: mutt hanging in endless loop
#2194: mutt hanging in endless loop
Changes (by brendan):
* component: mutt => display
Old description:
> {{{
> We have a central machine where people log in from home over DSL by ssh
> and read email with mutt. It pretty often happens that there are mutt
> processes running crazy, consuming 100% CPU.
>
> As far as we could track the problem, this occurs either in collission
> with procmail or especially when DSL lines have their daily disconnect.
> The user then gets a new IP address and has no chance to close the TCP
> connection or continue to use it. After timeout the operating system
> closes the TCP socket and thus the virtual terminal.
>
> However, mutt seems to be unable to cope with that condition. An ltrace
> shows that mutt runs in an endless loop:
> __xstat64(3, "restmail", 0xbfc64cfc) = 0
> wmove(0x812ccc8, 22, 2) = 0
> wrefresh(0x812ccc8, 0, 0xbfc653e8, 0x8063389, 0x812ccc8) = 0
> wtimeout(0x812ccc8, 600000, 0x80fe3f8, 0xb7f4838c, 0x812ccc8) = 600000
> memset(0xbfc64c98, '\000', 140) = 0xbfc64c98
> sigaction(2, 0xbfc64c98, NULL) = 0
> wgetch(0x812ccc8, 0xb7f49554, 0, 0x440d5afe, 0x8180f78) = -1
> memset(0xbfc64c98, '\000', 140) = 0xbfc64c98
> sigaction(2, 0xbfc64c98, NULL) = 0
> wtimeout(0x812ccc8, -1, 0x80fe3f8, 0xb7f4838c, 0x812ccc8) = -1
> __xstat64(3, "restmail", 0xbfc64cfc) = 0
>
> It seems as if mutt used the wgetch function of the curses library, but
> does not properly deal with the return value -1 (= ERR)
>
> mutt should learn how to deal with that and how to cope with loss of the
> terminal (it should terminate).
>
> regards
> Hadmut
>
> >How-To-Repeat:
> Don't know exactly how to run mutt in that condition. Maybe try the TCP
> timeout.
>
> >Fix:
> Please check all wgetch calls whether they deal with error conditions
> correctly.
>
> Usually mutt should react properly on SIGHUP. Is there any chance that
> mutt could be in an state where it ignores/drops a SIGHUP?
>
> }}}
New description:
We have a central machine where people log in from home over DSL by ssh
and read email with mutt. It pretty often happens that there are mutt
processes running crazy, consuming 100% CPU.
As far as we could track the problem, this occurs either in collission
with procmail or especially when DSL lines have their daily disconnect.
The user then gets a new IP address and has no chance to close the TCP
connection or continue to use it. After timeout the operating system
closes the TCP socket and thus the virtual terminal.
However, mutt seems to be unable to cope with that condition. An ltrace
shows that mutt runs in an endless loop:
{{{
__xstat64(3, "restmail", 0xbfc64cfc) = 0
wmove(0x812ccc8, 22, 2) = 0
wrefresh(0x812ccc8, 0, 0xbfc653e8, 0x8063389, 0x812ccc8) = 0
wtimeout(0x812ccc8, 600000, 0x80fe3f8, 0xb7f4838c, 0x812ccc8) = 600000
memset(0xbfc64c98, '\000', 140) = 0xbfc64c98
sigaction(2, 0xbfc64c98, NULL) = 0
wgetch(0x812ccc8, 0xb7f49554, 0, 0x440d5afe, 0x8180f78) = -1
memset(0xbfc64c98, '\000', 140) = 0xbfc64c98
sigaction(2, 0xbfc64c98, NULL) = 0
wtimeout(0x812ccc8, -1, 0x80fe3f8, 0xb7f4838c, 0x812ccc8) = -1
__xstat64(3, "restmail", 0xbfc64cfc) = 0
}}}
It seems as if mutt used the wgetch function of the curses library, but
does not properly deal with the return value -1 (= ERR)
mutt should learn how to deal with that and how to cope with loss of the
terminal (it should terminate).
regards
Hadmut
>How-To-Repeat:
Don't know exactly how to run mutt in that condition. Maybe try the TCP
timeout.
>Fix:
Please check all wgetch calls whether they deal with error conditions
correctly.
Usually mutt should react properly on SIGHUP. Is there any chance that
mutt could be in an state where it ignores/drops a SIGHUP?
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2194#comment:3>