To add a further refinement to this, I'm also getting the occasional
core dump of CVS with a signal 11.

The minimalist case is :

WinCVS client in flat mode. (All files in sandbox appear in files
window, and when passed to the CVS server, are passed with full path
names.)

Select 4-6 random files from the sandbox, making sure they are in
different directories.

Modify them, or do a forced commit.

If it works, keep adding 1 file at a time to the check-in list until
it fails. Usually less than 8 files/dirs should do it. These files
are all 2-6 lvls down in the sandbox.

I then replaced the logmsg.archive and logmsg.verify text in the
respective wrapper files with:
sleep 4

Check-ins worked normally from the WinCVS machine.

Restore the loginfo and verifymsg wrapper files.

In logmsg.verify and logmsg.archive, right after the BEGIN blocks, or
the last of the "use" statements, add:
sleep 4;
exit 0;

In other words, the perl interpreter is loading, and loading all the
modules requested, sleeping for 4 seconds, then exiting. CVS
continues to core dump just like the full script was executing.

Does CVS read all of the info on STDIN before starting to process the
directories, or are we getting buffer overflow because it paused to
load the perl interpreter.

This occurs with CVS v. 1.11.20 and 1.11.22.

Anyone else seen anything like this?



Alan

--- In cvszilla@yahoogroups.com, "aeatwood2" <aeatwood2@...> wrote:
>
> I'm getting a pretty consistent error when checking in multiple
> directories recursively.
>
> Your transaction id is: XXXX (continuing existing transaction)
> cvs commit: cannot exec /tmp/cvsymai90: Permission denied)
> cvs [commit aborted]: Message verification failed
>
> ***** CVS exited with code 1 *****
>
> This does NOT occure when directories are checked in one at a time.
>
> Server is Solaris 8 running cvs 1.11.20, and client is WinCVS 2.0.2.4.
> Transport agent is Putty 0.58. This behavior is consistent across
> Unix command lines, and versions of WinCVS back to 1.2 and Putty back
> to 0.54. This combination just gives more verbose error messages.
>
> Has anyone else seen ANYTHING like this? I don't thing the problem is
> CVSzilla per se. I think it is exposing an issue in 1) CVS, or 2)
> Solaris, in that order of probability. I can reproduce it in native
> command line checking out to my home directory on the server.
>
> Alan
>