Re: [Bug: 21.4.18] startls gets stuck
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Uwe" == Uwe Brauer
<oub(a)mat.ucm.es> writes:
Uwe> The odd thing is that everything seems to work, I am asked
Uwe> for the password, then the gmail smtp mail server sends the
Uwe> mail, *but* then gnus (and xemacs) gets stuck: the last
Uwe> message which appears is something like:
Uwe> 250 2.0.0 OK 1154349802 o45sm7514984nfa
Sounds like an smtpmail bug to me. :-P Seriously, Gmail gave the
protocol reply to say it's done, XEmacs posts it to the buffer, so the
first guess is that smtpmail is waiting for something that never comes
(eg, due to an overly strict regexp in the comint filter). If Simon
says not, I guess he's in the best position to diagnose since he knows
the internals of smtpmail best.
Did you see the backtrace? smtpmail.el blocked XEmacs, and C-g
generated a backtrace:
Debugger entered--Lisp error: (quit)
accept-process-output(#<process "SMTP" pid 13724 state:exit>)
smtpmail-read-response(#<process "SMTP" pid 13724 state:exit>)
...
I think XEmacs should return from accept-process-output if the server
has closed the connection (I believe that is what happened), instead
of waiting for more input that will never arrive. If this happened, I
think smtpmail.el would handle the situation correctly.
The code looks like:
(while (not (search-forward "\r\n" nil t))
(unless (memq (process-status process) '(open run))
(throw 'done nil))
(accept-process-output process)
(goto-char smtpmail-read-point))
So it will check the process status and return, if a-p-o would return
control to smtpmail.el.
Alternatively, smtpmail.el is inflooping here, but then I think it
would be a bug in process-status that says the connection is open/run
when it is in fact closed.
Uwe> Any help is appreciated, sending works but archiving not
and
Uwe> I am not sure whether this is a bug or a wrong setting.
You still have the mail in the buffer (and for Gnus, in the draft
folder), right? If not, that's a bug. However, whether the archiving
to the FCC folder happens or not is a design decision; as far as the
MUA knows, the mail was not successfully posted, so the transaction is
still active. The MUA should preserve the message *somewhere*, but
it's up to the MUA to decide how and where to do that. Some users
might get annoyed if their archives got cluttered up with duplicates
in cases where the mail *did* fail and they had to resent.
Right.
Uwe> According to Simon Josefsson the author of smtpmail.el
this
Uwe> seems to be an (X)Emacs bug.
So, Simon, what do you think is going wrong? Or are you just in a
hurry to go skydiving? ;-)
Right, I don't have much time to debug this... but from the
backtrace, it seems XEmacs is blocking, not smtpmail.el.
/Simon