Re: Free SmartCVS Professional license

[Mark D. Baushke]

Thomas Singer <cvs@smartcvs.com> writes:

> Will this fix be soon available in CVS 1.12.10? I don't want to build
> the CVS executable myself but use apt-get to fetch it.

Soon? Probably not. I don't know when Derek is planning to release the
cvs 1.12.10 version.

In any case, the fix has not (yet) been applied to the feature branch.
It would be great if someone could come up with a test case suitable for
sanity.sh that shows this problem has been fixed. It is probably also
desirable for someone to really look at the client.c handle_e function
and determine how and when it would also have this problem.

Message
  <http://lists.gnu.org/archive/html/bug-cvs/2002-07/msg00105.html>
(Re: Lost process output in pipe between Emacs and CVS) by Ian Lance
Taylor describes what is happening.

The implication is that both handle_m and handle_e will need similar
treatment in the general case.

The further suggestion in the thread of that set of messages was that the
'correct' way to deal with this problem was to move CVS away from using
stdio to avoid problems with non-blocking file descriptors impacting it.

        -- Mark

Patch against feature branch top-of-tree (cvs 1.12.9.1 at present).

ChangeLog entry:

        * client.c (handle_m): Hack to deal with ssh putting stderr
        into non-blocking mode and then used via 'cvs COMMAND 2>&1' which
        might put stdout unexpectedly into non-blocking mode. This could
        lead to fwrite() or fflush() failing with EAGAIN, but cvs not
        checking for the error.
        (Patch suggested by Frank Hemer <frank@hemer.org>.)

Index: src/client.c
===================================================================
RCS file: /cvs/ccvs/src/client.c,v
retrieving revision 1.376
diff -u -p -r1.376 client.c
--- src/client.c        12 Jul 2004 23:14:02 -0000      1.376
+++ src/client.c        14 Aug 2004 18:16:12 -0000
@@ -2560,6 +2560,9 @@ handle_wrapper_rcs_option( char *args, i
 static void
 handle_m( char *args, int len )
 {
+    fd_set wfds;
+    int s;
+
     /* In the case where stdout and stderr point to the same place,
        fflushing stderr will make output happen in the correct order.
        Often stderr will be line-buffered and this won't be needed,
@@ -2567,6 +2570,11 @@ handle_m( char *args, int len )
        based on being confused between default buffering between
        stdout and stderr.  But I'm not sure).  */
     fflush (stderr);
+    FD_ZERO(&wfds);
+    FD_SET(STDOUT_FILENO, &wfds);
+    s = select(STDOUT_FILENO+1,NULL,&wfds,NULL,NULL);
+    if (s < 1)
+        perror("cannot write to stdout");
     fwrite (args, len, sizeof (*args), stdout);
     putc ('\n', stdout);
 }