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

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

[Richard Stallman]

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?

------- Start of forwarded message -------
To: emacs-pretest-bug@gnu.org
Reply-to: cc@ivu-ac.de, christoph.conrad@gmx.de
Organization: Church of GNU Emacs
X-Public-Key: http://wwwkeys.de.pgp.net:11371/pks/lookup?op=get&search=0x1B488DEA
Subject: Re: Problem sending bigger mails with CVS Gnus + CVS Emacs
From: Christoph Conrad <cc@ivu-ac.de>
Date: Fri, 17 May 2002 15:50:13 +0200

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)
`----
------- End of forwarded message -------

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

[Simon Josefsson]

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)
> `----
> ----------

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

[Jason Rumney]

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?

Someone else reported bugs sending mail from VM with CVS Emacs on
MS-Windows about a week ago.  I suspect both problems are caused by
recent changes to the MS-Windows implementation of network functions to
support the :nowait and :server options to make-network-process.

-- 
Jason Rumney <jasonr@gnu.org>

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

[Richard Stallman]

Does it appear to you that some Emacs primitive ought to handle this
better?  Perhaps process-send-... needs to handle long data better.
It has code to try to handle that case, but the code may not work.

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

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> Does it appear to you that some Emacs primitive ought to handle this
> better?  Perhaps process-send-... needs to handle long data better.
> It has code to try to handle that case, but the code may not work.

There was a bug in process-send-string which prevented sending of more
than n characters in one line (500?).  This used to cause problems in
sql-mode when people wanted to use process-send-string to send entire
buffers to the process.  All lines where shorter than n, and thus
there was no breaking into chunks, and this caused deadlocks with the
process.  I cannot remember wether this was fixed.  The fix would
cause splitting into chunks every n bytes, or every n lines in
addition to the present splitting of long lines.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

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

[Simon Josefsson]

Alex said there was a bug in process-send-string under Windows
recently.  I wrongly assumed that the smtpmail.el bug was not related
to recent Emacs changes.  Cristoph, is it?  If it is I think it
doesn't make sense for me to look at it more until the elisp
primitives are fixed.

As for the general question -- since I send large amount of data
often, as long as the primitives work I don't see any critical need
for improvement.

There are two outstanding minor problems I know of when it comes to
subprocess.  Unfortunately, I think they are quite difficult to debug
since they have been around since probably 19.x or at least 20.x.
There are workarounds for them, so users shouldn't see them.

* Dead locks when sending much data.  Search for "dead" in nntp.el.  I
  haven't seen this myself, and perhaps it has already been fixed --
  imap.el doesn't use anything similar.

* "Blue moon" bug.  Search for "blue moon" in nntp.el and imap.el.  I
  know several people has tried to reproduce and debug this but
  failed.  The workaround in imap.el for this one was added fairly
  recently.

Richard Stallman <rms@gnu.org> writes:

> Does it appear to you that some Emacs primitive ought to handle this
> better?  Perhaps process-send-... needs to handle long data better.
> It has code to try to handle that case, but the code may not work.

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

[Richard Stallman]

    Someone else reported bugs sending mail from VM with CVS Emacs on
    MS-Windows about a week ago.  I suspect both problems are caused by
    recent changes to the MS-Windows implementation of network functions to
    support the :nowait and :server options to make-network-process.

Are you going to debug that problem?

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

[Richard Stallman]

    * Dead locks when sending much data.  Search for "dead" in nntp.el.  I
      haven't seen this myself, and perhaps it has already been fixed --
      imap.el doesn't use anything similar.

This is the sort of problem I was concerned about.  Can anyone reproduce
problems sending large amounts of data to a subprocess now?

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

[Jason Rumney]

Christoph, Tak,

Could you please try the following patch, and tell me if it has any
effect on the problems you reported with sending mail with Gnus and
Mew and the latest CVS Emacs.


*** process.c.~1.373.~	Mon May 20 21:41:59 2002
--- process.c	Mon May 20 22:41:50 2002
***************
*** 4810,4815 ****
--- 4810,4819 ----
  #ifdef EAGAIN
  		      || errno == EAGAIN
  #endif
+ #ifdef WSAENOBUFS
+ 		      /* MS-Windows uses WSAENOBUFS for a full buffer.  */
+ 		      || errno == WSAENOBUFS
+ #endif
  		      )
  		    /* Buffer is full.  Wait, accepting input; 
  		       that may allow the program

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

[Tak Ota]

20 May 2002 22:47:05 +0100: Jason Rumney <jasonr@gnu.org> wrote:

> Christoph, Tak,
> 
> Could you please try the following patch, and tell me if it has any
> effect on the problems you reported with sending mail with Gnus and
> Mew and the latest CVS Emacs.
> 
> 
> *** process.c.~1.373.~	Mon May 20 21:41:59 2002
> --- process.c	Mon May 20 22:41:50 2002
> ***************
> *** 4810,4815 ****
> --- 4810,4819 ----
>   #ifdef EAGAIN
>   		      || errno == EAGAIN
>   #endif
> + #ifdef WSAENOBUFS
> + 		      /* MS-Windows uses WSAENOBUFS for a full buffer.  */
> + 		      || errno == WSAENOBUFS
> + #endif
>   		      )
>   		    /* Buffer is full.  Wait, accepting input; 
>   		       that may allow the program
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Jason,

Unfortunately that did not fix the problem with Mew.  Let me know
what other information or trial may help you solve this problem.

-Tak


Debugger entered--Lisp error: (file-error "writing to process" "invalid argument" #<process mew-smtp-info-mail1.sjc.in.sel.sony.com>)
  process-send-region(#<process mew-smtp-info-mail1.sjc.in.sel.sony.com> 9001 10001)
  (let ((next ...)) (process-send-region pro cont next) (setq cont next) (setq i (1+ i)))
  (while (and (< cont ...) (not ...) (< i N)) (let (...) (process-send-region pro cont next) (setq cont next) (setq i ...)))
  (let ((cont ...) (sender ...) (inc 1000) (i 0) (N 10)) (set-buffer (process-buffer pro)) (when (and sender ...) (process-send-string pro ...) (let ... ... ... ...)) (while (and ... ... ...) (let ... ... ... ...)) (mew-smtp-set-cont pnm cont) (if (< cont ...) (let ... ...) (mew-smtp-set-cont pnm nil) (mew-smtp-set-timer pnm nil) (process-send-string pro ...)))
  (save-excursion (let (... ... ... ... ...) (set-buffer ...) (when ... ... ...) (while ... ...) (mew-smtp-set-cont pnm cont) (if ... ... ... ... ...)))
  mew-smtp-command-content(#<process mew-smtp-info-mail1.sjc.in.sel.sony.com> "mew-smtp-info-mail1.sjc.in.sel.sony.com")
  funcall(mew-smtp-command-content #<process mew-smtp-info-mail1.sjc.in.sel.sony.com> "mew-smtp-info-mail1.sjc.in.sel.sony.com")
  (and func (funcall func process pnm))
  (cond (next (mew-smtp-set-status pnm next) (setq func ...) (and func ...) (mew-smtp-set-string pnm nil)) (t (if ... ...) (mew-smtp-recover pnm str)))
  (cond ((and ... ...) (setq code ...) (setq next ...) (cond ... ...)) (t nil))
  (progn (set-buffer (process-buffer process)) (mew-smtp-set-string pnm str) (cond (... ... ... ...) (t nil)))
  (unwind-protect (progn (set-buffer ...) (mew-smtp-set-string pnm str) (cond ... ...)) (if (get-buffer obuf) (set-buffer obuf)))
  (let ((obuf ...)) (unwind-protect (progn ... ... ...) (if ... ...)))
  (if (bufferp (process-buffer process)) (let (...) (unwind-protect ... ...)))
  (mew-filter (mew-smtp-set-string pnm str) (cond (... ... ... ...) (t nil)))
  (let* ((pnm ...) (status ...) (str ...) next func code) (mew-smtp-debug (upcase status) string) (mew-filter (mew-smtp-set-string pnm str) (cond ... ...)))
  mew-smtp-filter(#<process mew-smtp-info-mail1.sjc.in.sel.sony.com> "354 Enter mail, end with \".\" on a line by itself\n")

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

[Christoph Conrad]

Hi Jason,

    > Could you please try the following patch, and tell me if it has
    > any effect on the problems you reported with sending mail with
    > Gnus and Mew and the latest CVS Emacs.

Tried it, but:

w32fns.c(7255) : error C2102: '&' erwartet L-Wert
(in english: '&' expects l-value)

      if (NILP (Fmember (font_name, lpef->list)))
	{
	  *lpef->tail = Fcons (Fcons (build_string (buf), width), Qnil);
!!!!!  lpef->tail = &(XCDR (*lpef->tail));
	  lpef->numFonts++;
	}

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

[Christoph Conrad]

Hi Simon,

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

Tried, works.

    > 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.

I omit this cause the former worked, ok?

Best regards,
Christoph Conrad
-- 
Dipl.-Ing. Christoph Conrad
Senior-Systementwickler "Zentrale Software"
IVU Traffic Technologies AG
Elisabethstr. 16, 52062 Aachen
Telefon: +49.241.4 70 51-0, Telefax: +49.241.4 70 51-89
mailto:Christoph.Conrad@ivu-ac.de, http://www.ivu.de

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

[Richard Stallman]

    There was a bug in process-send-string which prevented sending of more
    than n characters in one line (500?).

Can you remember which system this happened on?
Can you please try to reproduce it now?
There is code to try to split long lines.

      This used to cause problems in
    sql-mode when people wanted to use process-send-string to send entire
    buffers to the process.  All lines where shorter than n, and thus
    there was no breaking into chunks, and this caused deadlocks with the
    process.

That sounds like a separate bug.  There is code that tries to receive
output when the process input buffer is full, but it may not work.
Can you reproduce this now?

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

[Jason Rumney]

I am unable to reproduce the problem (I tried sending up to 8.5MB
with smtpmail.el, but it succeeded), so it would help if one of you
could debug this further.

The best way to approach this to start with is to set a breakpoint in
sys_write() in w32.c on the line (3548 in CVS version 1.75) that
reads...

	  DebPrint(("sys_read.send failed with error %d on socket %ld\n",
		    pfn_WSAGetLastError (), SOCK_HANDLE (fd)));

If that line is not hit, we know that the problem is occurring at a
higher level.  If it is hit, then it would be useful to know what
error is occurring.  I'm not sure if gdb hooks into DebPrint system
calls, so you may need to check the value of h_errno after that line
has executed.

If you updated from CVS recently, you may need to back out to
2002-05-18 to get w32fns.c to compile.


Tak Ota <Takaaki.Ota@am.sony.com> writes:

> 20 May 2002 22:47:05 +0100: Jason Rumney <jasonr@gnu.org> wrote:
> 
> > Christoph, Tak,
> > 
> > Could you please try the following patch, and tell me if it has any
> > effect on the problems you reported with sending mail with Gnus and
> > Mew and the latest CVS Emacs.
> > 
> > 
> > *** process.c.~1.373.~	Mon May 20 21:41:59 2002
> > --- process.c	Mon May 20 22:41:50 2002
> > ***************
> > *** 4810,4815 ****
> > --- 4810,4819 ----
> >   #ifdef EAGAIN
> >   		      || errno == EAGAIN
> >   #endif
> > + #ifdef WSAENOBUFS
> > + 		      /* MS-Windows uses WSAENOBUFS for a full buffer.  */
> > + 		      || errno == WSAENOBUFS
> > + #endif
> >   		      )
> >   		    /* Buffer is full.  Wait, accepting input; 
> >   		       that may allow the program
> > 
> > 
> > _______________________________________________
> > Emacs-devel mailing list
> > Emacs-devel@gnu.org
> > http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
> Jason,
> 
> Unfortunately that did not fix the problem with Mew.  Let me know
> what other information or trial may help you solve this problem.

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

[Tak Ota]

21 May 2002 21:32:00 +0100: Jason Rumney <jasonr@gnu.org> wrote:

> The best way to approach this to start with is to set a breakpoint in
> sys_write() in w32.c on the line (3548 in CVS version 1.75) that
> reads...
> 
> 	  DebPrint(("sys_read.send failed with error %d on socket %ld\n",
> 		    pfn_WSAGetLastError (), SOCK_HANDLE (fd)));
> 
> If that line is not hit, we know that the problem is occurring at a
> higher level.  If it is hit, then it would be useful to know what
> error is occurring.  I'm not sure if gdb hooks into DebPrint system
> calls, so you may need to check the value of h_errno after that line
> has executed.

It is hit.  pfn_WSAGetLastError returned 10035 which is WSAEWOULDBLOCK
(WSABASEERR+35) according to WINSOCK.H.

> If you updated from CVS recently, you may need to back out to
> 2002-05-18 to get w32fns.c to compile.

Yes, I have been using that trick :)

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

[Tak Ota]

Jason,

I've modified sys_write in the same manner that _sys_read_ahead
performs blocking IO then the problem disappeared.  Is this a right
fix?  The sys_write comment explicitly states that;

/* For now, don't bother with a non-blocking mode */

-Tak


*** emacs-21.2.50/src/w32.c	Sat May  4 07:53:43 2002
--- w32.c	Tue May 21 18:26:34 2002
***************
*** 2568,2573 ****
--- 2568,2574 ----
      case WSAEMFILE:		h_errno = EMFILE; break;
      case WSAENAMETOOLONG: 	h_errno = ENAMETOOLONG; break;
      case WSAENOTEMPTY:		h_errno = ENOTEMPTY; break;
+     case WSAEWOULDBLOCK:	h_errno = EAGAIN; break;
      }
    errno = h_errno;
  }
***************
*** 3541,3548 ****
--- 3542,3561 ----
  #ifdef HAVE_SOCKETS
    if (fd_info[fd].flags & FILE_SOCKET)
      {
+       unsigned long nblock = 0;
        if (winsock_lib == NULL) abort ();
+ 
+       /* We always want this to block, so temporarily disable NDELAY.  */
+       if (fd_info[fd].flags & FILE_NDELAY)
+ 	pfn_ioctlsocket (SOCK_HANDLE (fd), FIONBIO, &nblock);
+ 
        nchars =  pfn_send (SOCK_HANDLE (fd), buffer, count, 0);
+ 
+       if (fd_info[fd].flags & FILE_NDELAY)
+ 	{
+ 	  nblock = 1;
+ 	  pfn_ioctlsocket (SOCK_HANDLE (fd), FIONBIO, &nblock);
+ 	}
        if (nchars == SOCKET_ERROR)
          {
  	  DebPrint(("sys_read.send failed with error %d on socket %ld\n",

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

[Tak Ota]

Jason,

21 May 2002 21:32:00 +0100: Jason Rumney <jasonr@gnu.org> wrote:

> I am unable to reproduce the problem (I tried sending up to 8.5MB
> with smtpmail.el, but it succeeded), so it would help if one of you
> could debug this further.

I was wondering why you didn't see the same problem.  I now have a
possible explanation.  smtpmail.el's smtpmail-via-smtp calls
process-send-string per message line repetitively therefore the size
of data passed to pfn_send is limited to the maximum line length no
matter how large the message is as a whole.  On the other hand, Mew
uses process-send-region and pushes maximum of 1000 byes out to
pfn_sned at a time.  This difference might be revealing sys_write's
following feature differently.

/* For now, don't bother with a non-blocking mode */

-Tak

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

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     There was a bug in process-send-string which prevented sending of more
>     than n characters in one line (500?).
>
> Can you remember which system this happened on?

Windows.

> Can you please try to reproduce it now?

At work, where I still use Windows, I still have Emacs 20.7, so I
don't know how much that will help.

> There is code to try to split long lines.

Right, I think what was missing was spliting between lines.  When
people sent their entire buffer and every line of the buffer was
"short", then this would trigger the deadlock.

>       This used to cause problems in
>     sql-mode when people wanted to use process-send-string to send entire
>     buffers to the process.  All lines where shorter than n, and thus
>     there was no breaking into chunks, and this caused deadlocks with the
>     process.
>
> That sounds like a separate bug.  There is code that tries to receive
> output when the process input buffer is full, but it may not work.
> Can you reproduce this now?

Not on my GNU/Linux system with the following script used as the bogus
interpreter:

#! /bin/bash
read -p "SQL> "
LINE=1
while true; do
    LINE=$(($LINE + 1))
    case $REPLY in
	*\;)
	    echo "foo!"
	    read -p "SQL> "
	    LINE=1
	;;
	*)
	    read -p "  $LINE: "
	;;
    esac
done

I will try and remember to run the appropriate test when I install
Emacs 21 on a Windows machine.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

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

[Richard Stallman]

    > That sounds like a separate bug.  There is code that tries to receive
    > output when the process input buffer is full, but it may not work.
    > Can you reproduce this now?

    Not on my GNU/Linux system with the following script used as the bogus
    interpreter:

It could be a Windows-only bug.