On 23Nov2012 10:42, John Long <codeb...@inbox.lv> wrote: | On Thu, Nov 22, 2012 at 11:40:33PM +0100, Richard wrote: | > On Thu, Nov 22, 2012 at 06:42:27PM +0000, John Long wrote: | > > My mutt on Linux has been locking up lately. I didn't compile it with debug | > > support. Is there any way to figure out why this is happening? I sometimes | > > lock up in the middle of composing a long email or when mutt has been open | > > for awhile. This didn't happen until this week and I suspect my email | > > provider is messing up but I don't know how to check it. Once in awhile mutt | > > becomes non-responsive and there's nothing I can do but kill it or close the | > > terminal window. It doesn't respond to any keypresses. | > | > first thing to try is "strace -p pid-mutt" from a different terminal. | | Thanks, that fixed it! Just like when you take your car to the shop, it | never exhibits the problem...I started strace this morning and the damn | thing's been running fine for hours already!
Some things are timing dependent, and strace does affect things; best to _not_ strace, wait for failure, _then_ strace. You can also do more trageted stracing with the -e option, eg: strace -e trace=file -p mutt-pid If mutt has gone CPU bound it won't say anything, but if a system call is hanging or mutt is spinning on one (I've seen Linux futexes do this frequently, outstandingly annoying) it should show something. Hopefully a call using a file path or file descriptor. If the latter, lsof -p pid-mutt should show you what that file descriptor is associated with. OTOH, if mutt is CPU bound and doing no system calls, gdb for a stace backtrace may be illuminating. Cheers, -- Cameron Simpson <c...@zip.com.au> Reaching consensus in a group often is confused with finding the right answer. - Norman Maier
