<<< Date Index >>>     <<< Thread Index >>>

mutt/2194: mutt hanging in endless loop



>Number:         2194
>Notify-List:    
>Category:       mutt
>Synopsis:       mutt hanging in endless loop
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    mutt-dev
>State:          open
>Keywords:       
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 08 18:39:26 +0100 2006
>Originator:     Hadmut Danisch
>Release:        1.5.11+cvs20060126-2
>Organization:
>Environment:
Debian Linux
>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?

>Add-To-Audit-Trail:

>Unformatted: