Re: nnimap versus tls

[Gaute B Strokkenes <gs234@cam.ac.uk>]

On  9 jul 2003, kai.grossjohann@gmx.net wrote:

> Gaute B Strokkenes <gs234@cam.ac.uk> writes:
>
>> However, the fix as it stands is not complete.  Consider the
>> following (parital) backtrace:
>>
>> Debugger entered--Lisp error: (error "Selecting deleted buffer")
>> imap-arrival-filter(#<process imap<1>> "*** Received corrupted data(-9) - server has terminated the connection abnormally\n")
>> delete-process(#<process imap<2>>)
>> imap-close(#<buffer  *imap source*>)
>>
>> See?  gnutls-cli likes to spit out that line "*** Received
>> corrupted"... after the connection is closed.  If emacs (and thus
>> imap-arrival-filter) receives that line separately from the
>> previous one, then there is a chance that that lone line will still
>> be awaiting processing after imap-close returns, and so we loose.
>
> Argh.  What happens with (while (accept-process-output ...))?  That
> means we keep reading stuff until it's enough.

The thing is, the a subprocess is allowed to give us its output in
however small or large pieces that it feels like, timed in whatever
fashion it fells like.  gnutls-cli seems to like to feed us things
line-by-line; thus the scenario is eminently possible:


gnutls-cli feeds us "6 OK LOGOUT completed"

we read "6 OK LOGOUT completed" with accept-process-output, which
returns non-nil.

Since it returned non-nil, we call accept-process-output again, which
returns nil.

gnutls-cli feeds us "*** Received corrupted data blah-blah", and then
dies.

We check (process-status imap-process) and find that it is dead, and
so return immediately.

Using such a loop would probably make the problem much less likely to
occur, but it _could_ still happen.  And anyway, since it's easy to do
the right thing in all cases, there is no reason not do.

> Probably you already tried it, though.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
I left my WALLET in the BATHROOM!!