Re: [cc@ivu-ac.de: Re: Problem sending bigger mails with CVS Gnus + CVS Emacs]

[Simon Josefsson <jas@extundo.com>]

This bug might be related to the "deadlock" workarounds in Gnus --
whenever lots of data is sent, it calls `accept-process-output' once
in a while to prevent deadlocks (see e.g. nntp.el, search for "dead").
However, I'm often sending multi-MB mail using smtpmail.el, so I
suspect it is a subtle bug (I'm using redhat, the reporter is using
windows).

Christoph, can you try this patch instead of your defadvice?

Also, please frob smtpmail-debug-info to non-nil and mail the contents
in the *trace of SMTP session to server* buffer after sending a large
mail.

smtpmail.el is not very nicely coded, it calls process-send-* in lots
of places without first checking if the process is still alive.  So if
the connection is dropped or similar, the code will always cause the
elisp error you got.

--- smtpmail.el.~1.44.~	Tue May 14 23:56:46 2002
+++ smtpmail.el	Sun May 19 02:01:50 2002
@@ -832,10 +832,12 @@
   (setq smtpmail-read-point (point))
   ;; Escape "." at start of a line
   (if (eq (string-to-char data) ?.)
-      (process-send-string process "."))
-  (process-send-string process data)
-  (process-send-string process "\r\n")
-  )
+      (when (memq (process-status process) '(open run))
+	(process-send-string process ".")))
+  (when (memq (process-status process) '(open run))
+    (process-send-string process data))
+  (when (memq (process-status process) '(open run))
+    (process-send-string process "\r\n")))
 
 (defun smtpmail-send-data (process buffer)
   (let
@@ -847,7 +849,8 @@
     (with-current-buffer buffer
       (goto-char (point-min)))
 
-    (while data-continue
+    (while (and data-continue
+		(memq (process-status process) '(open run)))
       (with-current-buffer buffer
 	(beginning-of-line)
 	(setq this-line (point))
@@ -859,6 +862,7 @@
 	    (setq data-continue nil)))
 
       (smtpmail-send-data-1 process sending-data)
+      (accept-process-output process 0)
       )
     )
   )


Richard Stallman <rms@gnu.org> writes:

> Can you do the right thing about this?  Or if it is due to a problem
> in Emacs primitives, could you explain the problem to us so someone
> can try to fix it?
>
> From: Christoph Conrad <cc@ivu-ac.de>
> Subject: Re: Problem sending bigger mails with CVS Gnus + CVS Emacs
> To: emacs-pretest-bug@gnu.org
> Date: Fri, 17 May 2002 15:50:13 +0200
> Reply-to: cc@ivu-ac.de, christoph.conrad@gmx.de
> Organization: Church of GNU Emacs
>
> In GNU Emacs 21.2.50.1 (i386-msvc-nt4.0.1381)
>  of 2002-05-17 on CLI119
> configured using `configure --with-msvc (12.00)'
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: DEU
>   locale-coding-system: iso-latin-1
>   default-enable-multibyte-characters: nil
>
> I have some strange problem (and a workaround) with CVS Gnus and CVS
> Emacs, both from today.
>
> When i try to send a mail which is a little bit bigger than about 40K
> the following lines are in /var/log/mail
>
> ,----
> | May 17 13:14:11 cli3 sendmail[23841]: g4HBCja23841: collect: premature EOM: Error 0
> | May 17 13:14:11 cli3 sendmail[24045]: g4HBDxa24045: collect: unexpected close on connection from cli119.cli.de, sender=<cc@ivu-ac.de>: Error 0
> `----
>
> and Emacs reports: "writing to process, invalid argument, SMTP
>
> The workaround is to
>
> (defadvice smtpmail-send-data(around smtpmail-send-data-delay act)
>   (sleep-for 1)
>   ad-do-it)
>
> which simply makes a pause of 1 sec in smtpmail.el's code:
>
> ,----
> |   ;; DATA
> |   (smtpmail-send-command process "DATA")
> | 
> |   (if (or (null (car (setq response-code (smtpmail-read-response process))))
> |           (not (integerp (car response-code)))
> |           (>= (car response-code) 400))
> |       (throw 'done nil)
> |     )
> |
> |   ;; !!!! here: wait 1 sec 
> |   ;; Mail contents
> |   (smtpmail-send-data process smtpmail-text-buffer)
> `----
> ----------