[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs loops in gettimeofday() while fetching header of certain mail



INOUE Katsumi <kinoue@jp.oracle.com> writes:

> This problem began when my boss forwarded me a mail with long
> filename attachment and with a large "To:" address.
> 
> After this mail arrived on backend, all of my attempts to 
> browse my INBOX failed resulting in high CPU usage without
> doing anything.

You later said that C-g worked, so, could you evaluate `(setq
debug-on-quit t)' and repeat the above, press C-g and mail me the
backtrace?

You'll probably find that it's stuck inside `imap-wait-for-tag', if
so, please mail me the last lines of *imap-log* so I can see why it
didn't parse everything there.

> I was stuck so I switched to Netscape and created a new folder on
> backend and moved this mail in it. Then I restarted emacs but still
> couldn't browse this newly created folder in gnus.

My bet it's a bug in the IMAP parser. One such bug was fixed in 0.90,
but there are probably more.

If the IMAP parser fails, then it will wait forever for something it
has already received but failed to parse.

> Can anybody guess what gnus is doing in the gettimeofday() loop?

This is Emacs, and it is normal.

Perhaps someone should benchmark gettimeofday() on different systems,
and if actually takes some time, then perhaps optimize Emacs not to
call it so often -- but that's just optimizing.

> Actually, I have encountered more serious problem in that
> emacs gets into endless gettimeofday() loop.
> I had to kill emacs several times.
> But I guess this is either RedHat linux glibc problem or
> generic linux or emacs problem.

You probably encountered a Emacs bug that made the UI hung (they
aren't too uncommon, unfortunely), but the internals kept working.

If you can reproduce this situation I think a report to the Emacs
people would be good. Developing nnimap, Emacs/XEmacs hangs on me
every day, but I haven't really been able to pin-point it to anything
more specific than "developing nnimap".