Re: Free SmartCVS Professional license

[Frank Hemer]

On Saturday 14 August 2004 20:33, Mark D. Baushke wrote:
> 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.

Stderr might happen to be in nonblocking mode. So every call to stdio that 
doesn't handle nonblock conditions is possibly affected.
I'm not familiar with setting up a test case for sanity.sh, but I could come 
up with a description of what has to be done to reproduce the error.

Frank

> 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);
>  }