Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix

[Derek Robert Price]

Larry Jones wrote:

> Derek Robert Price writes:
>  
>
> > The CVS protocol is set up so that the CVS client and server exchange a 
> > list of supported-requests.  What if, and I'll have to review the 
> > protocol to figure out exactly which request this should be done with, 
> > but what if one of the requests that is sent every time has its name 
> > changed.  Or better yet, clients version 1.11.2 and later send a new 
> > protocol string that says "I'll close compressed connections".  Then the 
> > server can use the old method when it doesn't recieve that command and 
> > the new when it does.
> >    
>
> I really don't like that idea.  This doesn't seem like the kind of thing
> we need to amend the client/server protocol to address -- the benefits
> of checking for stray trailing data from the client are so small that,
> on further reflection, I don't think we're giving up enough to make it
> worth worrying about.  It also strikes me as a bit presumptious of the
> buffering library to take it upon itself to comment on how it's being
> used; if the caller decides to shut down an input buffer prematurely,
> what gives the buffering library the right to complain about it?
>
> In fact, I wonder if that works at all -- if the server shuts down
> prematurely (due to receiving a signal, for example) while receiving
> input from a compressed connection, does its buffer shutdown wait for
> the client to shut down?  Does the client necessarily get notified that
> all is lost so it even knows to shut down?
>  

Actually, at least in the case of a spurious SIGPIPE, in this case 
delivered via kill -15, the client ends up spitting out a bunch of file 
contents on STDERR with each line prefixed by `cvs checkout: warning: 
unrecognized response' and then both lock and hang.

Incidentally, has anyone else come across hanging servers which seem to 
be blocking somewhere underneath  SIG_handle with sig=13?  Is there any 
reason the server would receive a SIGPIPE which didn't come from the 
client?  Killing child server processes with both SIGTERM and SIGKILL 
seems to be handled correctly.

> > Alternatively, there must be a way to install a 30 second timeout or 
> > something around that call to getc().
> >    
>
> That's actually quite difficult to do portably, particularly since stdio
> is involved in the process.
>  

Okay.  I removed the getc() from the line and it passed `make test', so 
I checked in a fix if anyone would like to test the new server with an 
old client.

The server still hangs in response to a spurious SIGPIPE, though.  Not 
in the same location I've been seeing however, and I didn't get the 
garbled output on the client side this time, but that could just be timing.

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
--
Funny noises are not funny.
Funny noises are not funny.
Funny noises are not funny...

         - Bart Simpson on chalkboard, _The Simpsons_