Date: Fri, 13 Nov 1998 15:29:10 +0000
To: bug-cvs@gnu.org
From: J Cone <the_cone@g8labs.com>
Subject: cvs add; cvs commit dumps core
Cc: andy_taylor@g8labs.com
Content-Type: text/plain; charset="us-ascii"
Sender: owner-bug-cvs-list@cyclic.com
Precedence: bulk

Dear Sir/Madam,

I have a situation where CVS dumps core in fputentent, possibly after
dereferencing a null pointer in write_ent_proc.  As I cannot find it in the
BUGS and MINOR-BUGS, I wonder if you could reproduce and log it.

SHORT DESCRIPTION
=================

If a file is 'cvs add'ed at a high revision number (eg 4.*; revision
numbers chosen with cvs update), rcs reports an error on the 'cvs commit'
and the incurs a segmentation fault.  After cleaning up the locks, the
module is inconsistent about whether the file exists, and fails to add
other files.

TO REPRODUCE
============
$ export CVSROOT=/export/home/jcone/tmp/cvs/CVS
$ cvs init                                     
$ mkdir TEST
$ cd TEST
$ cvs import -m "Test Module" TEST jcone start
 
No conflicts created by this import
 
$ cd ..
$ rmdir TEST
$ cvs checkout TEST
cvs checkout: Updating TEST
$ cd TEST
$ touch file1
$ cvs add file1
cvs add: scheduling file `file1' for addition
cvs add: use 'cvs commit' to add this file permanently
$ cvs commit -m "Add file1"
cvs commit: Examining .
RCS file: /export/home/jcone/tmp/cvs/CVS/TEST/file1,v
done
Checking in file1;
/export/home/jcone/tmp/cvs/CVS/TEST/file1,v  <--  file1
initial revision: 1.1
done
$ cvs update -r 4
cvs update: Updating .
cvs update: file1 is no longer in the repository
$ touch file1
$ cvs add file1
cvs add: scheduling file `file1' for addition on branch `4'
cvs add: use 'cvs commit' to add this file permanently
$ cvs commit -m "Add new file1"
cvs commit: Examining .
Checking in file1;
/export/home/jcone/tmp/cvs/CVS/TEST/file1,v  <--  file1
new revision: 1.2; previous revision: 1.1
done
Segmentation Fault(coredump)
$ cd /export/home/jcone/tmp/cvs/CVS/TEST
$ ls
#cvs.lock              #cvs.wfl.dilbert.5972  file1,v
$ rmdir '#cvs.lock'; rm '#cvs.wfl.dilbert.6004'
$ cd /export/home/jcone/tmp/cvs/TEST
  **1
$ cvs status file1
===================================================================
File: file1             Status: Locally Added
 
   Working revision:    New file!
   Repository revision: No revision control file
   Sticky Tag:          4 - MISSING from RCS file!
   Sticky Date:         (none)
   Sticky Options:      (none)
 
$ cd ..
$ cvs checkout -d TEST.1 TEST
cvs checkout: Updating TEST.1
$ cd TEST.1
$ cvs status file1
  **2
===================================================================
File: no file file1             Status: Needs Checkout
 
   Working revision:    No entry for file1
   Repository revision: 1.2
/export/home/jcone/tmp/cvs/CVS/TEST/Attic/file1,v
 
$ cvs update file1
U file1
$ cvs status file1
  **3
===================================================================
File: file1             Status: Up-to-date
 
   Working revision:    1.2     Fri Nov 13 15:12:36 1998
   Repository revision: 1.2
/export/home/jcone/tmp/cvs/CVS/TEST/Attic/file1,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)
 
$ cvs update -r 4
cvs update: Updating .
cvs update: file1 is no longer in the repository
$ cvs status file1
  **4
===================================================================
File: no file file1             Status: Unknown
 
   Working revision:    No entry for file1
   Repository revision: No revision control file


ANALYSIS
========
At **1, the file is newly added; at **2, it seems not to exist, and at **3
it does, but not (at **4) on the branch I asked for; so something, probably
the repository, is now inconsistent.

After the core dump, CVS leaves behind an 'Attic' directory containing the
rcs (*,v) file in the repository.  I suspect that every controlled file is
intended to have an RCS file in either the parent directory or the Attic
directory, but not both.  I suspect that the standard protocol for changing
a file involves
  - move it into Attic
  - have RCS
      - read from Attic
      - have temporary files in /tmp
      - write to the parent directory
and that CVS relies on finding the file written by RCS.

Having CVS cope with the RCS file in the parent directory being missing
(and probably report failure and move it back from Attic) would be good.

Can anyone provide advice about any of
  - the correctness of my guesses
      (I haven't seriously read the code yet)
  - how to sanity check the repository
  - how to make the repository consistent
  - how to fix CVS so it creates a 4.1 file

Thanks,
James.