Re: Infinite loop in pop3-retr

[Tomasz Gajewski <tomga@wp.pl>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Sometimes during retrieving mail through pop3 in gnus I emacs loops
>> infinitely in pop3-retr. It seems to be somehow connected with some
>> buggy mail. Normally I didn't have time to investigate it thoroughly
>> (I haven't used emacs debugger yet) but this time I think I've found
>> out enough to make this problem fixed by someone.
>>
>> Problem is inside:
>>   (set-buffer (process-buffer process))
>>   (while (not (re-search-forward "^\\.\r\n" nil t))
>>     (pop3-accept-process-output process)
>>     (goto-char start))
>
>> If I correctly read it this code assumes that in (process-buffer
>> process) finally will contain line with dot only but this never
>> happens probably due to information found at the end of trace of pop
>> session to server saying:
>
>> Process POP connection broken by remote peer.
>
>> Can you propose some fix for this?
>
> The while should also test whether the `process' is still alive.  Or
> else, pop3-accept-process-output should somehow signal an error if
> `process' is not alive any more.

I have no experience with emacs lisp programming and I don't like my
solution (but it is the only one I could find).

   (set-buffer (process-buffer process))
   (while (and (not (re-search-forward "^\\.\r\n" nil t))
               (member (process-status process)
                                       (list 'run 'stop 'open
                                             'listen 'connect)))
     (pop3-accept-process-output process)
     (goto-char start))

Firstly, I think that probably there is a simpler way to check if
process is active than by testing process status but I don't know that.

Secondly, I can't test this code right now becuase problem happens only
sometimes.

Can someone with more experience update this code (or maybe say that it
is not required)?

Should I sent a bug report with those informations somewhere (gnus bugs
list, emacs bugs list) or is it sufficient leave it here?

Regards

-- 
Tomasz Gajewski