[cvsnt] Cvsnt hangs the w2k server, v 1.11.1.3 (build 57d)

John Peter Arnold jparn at ar-ent.net
Sun Feb 2 12:22:19 GMT 2003


Synopsis
The cvs server hogs the w2k machine by bringing the cpu occupation up to
100% and by allocating memory until the entire machine becomes unreachable.

We have determined that this situation happens when a "cvs status" command
is given and the local Entries file is invalid. The problem is a badly set
sticky tag in one of the files. This is shown in the following example.

      /driver.c/1.4/Sun Feb 2 10:23:07 2003//TS001-001
      /gabri.c/1.2/Sun Feb 2 10:23:07 2003//TS001-001
      /pippo.c/1.3/Tue Jan 28 16:48:48 2003//TS001-001
      /pluto.c/1.1/Wed Oct 16 12:36:18 2002//TS001-001
      /plutox.c/1.2/Wed Oct 30 09:32:14 2002//TS001-001
      /peter.c/1.1/Sun Feb 2 10:38:13 2003//T
      D


There appear to be two separate problems. The first problem is the sequence
with wich the improper Entries file comes to be. The second problem is that
the cvs server looses control when confronted by an empty sticky tag.

We have reproduced the sequence necessary to recreate the situation.

Step One
We checkout a simple test project in two separate workspaces. The project
contains the following files:

      driver.c
      gabri.c
      pippo.c
      pluto.c
      plutox.c


The files have a certain number of revisions and a common sticky label ---
named s001-001 --- has been attached to each file.

      ===================================================================

      File: driver.c Status: Up-to-date
      Working revision: 1.5
      Repository revision: 1.5 y:/cvsroot01/test/driver.c,v
      Sticky Tag: (none)
      Sticky Date: (none)
      Sticky Options: (none)
      Existing Tags:
      S001-001 (revision: 1.4)
      BR-2002-ac (branch: 1.3.2)

      ===================================================================
      File: gabri.c Status: Up-to-date
      Working revision: 1.3
      Repository revision: 1.3 y:/cvsroot01/test/gabri.c,v
      Sticky Tag: (none)
      Sticky Date: (none)
      Sticky Options: (none)
      Existing Tags:
      S001-001 (revision: 1.2)
      ===================================================================
      File: pippo.c Status: Up-to-date
      Working revision: 1.3
      Repository revision: 1.3 y:/cvsroot01/test/pippo.c,v
      Sticky Tag: (none)
      Sticky Date: (none)
      Sticky Options: (none)
      Existing Tags:
      S001-001 (revision: 1.3)
      BR-2002-ac (branch: 1.1.2)
      ===================================================================
      File: pluto.c Status: Up-to-date
      Working revision: 1.1
      Repository revision: 1.1 y:/cvsroot01/test/pluto.c,v
      Sticky Tag: (none)
      Sticky Date: (none)
      Sticky Options: (none)
      Existing Tags:
      S001-001 (revision: 1.1)
      BR-2002-ac (branch: 1.1.2)
      ===================================================================
      File: plutox.c Status: Up-to-date
      Working revision: 1.2
      Repository revision: 1.2 y:/cvsroot01/test/plutox.c,v
      Sticky Tag: (none)
      Sticky Date: (none)
      Sticky Options: (none)
      Existing Tags:
      S001-001 (revision: 1.2)
      BR-2002-ac (branch: 1.1.2)


The cvs subdirectory contains:

      Entries
      Repository
      Root


The Entries file contains:

      /driver.c/1.5/Sun Feb 2 09:50:19 2003//
      /gabri.c/1.3/Sun Feb 2 09:50:19 2003//
      /pippo.c/1.3/Tue Jan 28 16:48:48 2003//
      /pluto.c/1.1/Wed Oct 16 12:36:18 2002//
      /plutox.c/1.2/Wed Oct 30 09:32:14 2002//
      D


Step Two
We move to the first workspace and lock it to label s001-001 by giving the
command "cvs upd -r S001-001".

The cvs subdirectory contains:

      Entries
      Repository
      Root
      Tag


The Entries file contains:

      /driver.c/1.4/Sun Feb 2 10:23:07 2003//TS001-001
      /gabri.c/1.2/Sun Feb 2 10:23:07 2003//TS001-001
      /pippo.c/1.3/Tue Jan 28 16:48:48 2003//TS001-001
      /pluto.c/1.1/Wed Oct 16 12:36:18 2002//TS001-001
      /plutox.c/1.2/Wed Oct 30 09:32:14 2002//TS001-001
      D


But the Tag file contains:

      N


This seems to us to be the root of the problem. According to Cederqvist 2.3
pp 16 the letter 'n' indicates a non-branch tag and should be followed by
the tag.

Step Three
We move to the sencond workspace --- the one without the sticky tag --- and
create a new file peter.c. We add it to the repository. We commit. We assign
tag s001-001 to the first revision of the file.

Step Four
We move back to the first workspace and issue command "cvs upd". The new
file is properly added and all seems well. But the Entries file contains:

      /driver.c/1.4/Sun Feb 2 10:23:07 2003//TS001-001
      /gabri.c/1.2/Sun Feb 2 10:23:07 2003//TS001-001
      /pippo.c/1.3/Tue Jan 28 16:48:48 2003//TS001-001
      /pluto.c/1.1/Wed Oct 16 12:36:18 2002//TS001-001
      /plutox.c/1.2/Wed Oct 30 09:32:14 2002//TS001-001
      /peter.c/1.1/Sun Feb 2 10:38:13 2003//T
      D


Notice that file peter.c contains an empty tag lable. This could be caused
by the empty label in the Tag file we have just discussed.

Step Five
We issue command "cvs status peter.c". We rapidly gain control of the cvs
server and observe that cvs.exe has a 100% cpu occupation and is allocating
memory at a fantastic rate. We just manage to kill the process before it
brings the w2k machine to its knees.

If the Entries file is manually fixed the problem dissapears.

Alternatively if command "cvs upd -r S001-001 peter.c" is given the Entries
file is corrected.







More information about the cvsnt mailing list