1.11.[2&9], server abort, "unable to parse"

[Todd Denniston]

Short: I think something bad happened between 1.11.1p1 and 1.11.2 to the rcs 
file parsing on loaded machines. And I would like some help locating the
offending change.

Also I am not subscribed to bug-cvs, so please either copy me on the responses 
or copy cvs-info as I am subscribed there.

Long: read the following novel. :)

I was finally updating our server to an 1.11.x version and ran into a hitch.
For our biggest project (~430 Mega Bytes under cvs) random errors started 
happening after I changed to 1.11.9.  I switched the pserver back to 1.10.7
and everything was fine, so I started checking other revs between that I had 
installed (for my projects use) and found that the errors could be
consistently created when the server was 1.11.2 & 1.11.9 ( I do not have any 
between those installed) and that we have been unable to create any
errors when the server was using versions 1.11, 1.11.1 & 1.11.1p1. It should be 
noted that cvs 1.11.2&9 does not always error out on the same file,
and sometimes will run through successfully.  The neither the version of the 
client, nor the remote access method have made any difference, in either
the success or fail cases.

I have used the script found at:
http://people.redhat.com/dledford/memtest.html
to test the machine's memory and using the cm disk as its playground (hoping 
that if it was a disk problem it might catch that too), it found nothing
wrong.

running check_cvs (with cvs-1.11) finds some files which it claims are 
corrupted and I agree with it that there is something wrong with the files, as
most are in a directory called RCS/Attic/ and have the extension ',v,v', and 
the other two are in an Attic directory and all of them have not been
changed since 1999. I will get permission to remove these files (they really do 
not look like they ever were used) and if that fixes this I will let
you know, however I do not expect it to change things as the errors I get have 
been in other directories.


>Submitter-Id:   net
>Originator:     Todd Denniston
>Organization:  net
>Confidential:  no
>Synopsis:      server abort, "unable to parse"
>Severity:      critical
>Priority:      medium 
>Category:      cvs
>Class:         sw-bug 
>Release:       1.11.2&9
>Environment:
System: SunOS 5.6 Generic_105181-12 sun4u sparc SUNW,Ultra-2
Architecture: sun4

gcc --version = 2.95

`du -h` of repository: 427M
clients: 1.10.7 & 1.11.9, from experiments I believe this problem is only on 
the server.

>Description:
Note: PROJNAME has been put in place of the four character name of the project.

using pserver or ext (rsh) without a -z option.
when commands such as `cvs diff` or `cvs checkout PROJNAME` are issued, during 
almost random runs errors will be generated such as:
cvs [diff aborted]: unable to parse /cm/REPOSITORY/PROJNAME/FILENAME.H,v; 
`state' not in the expected place

OR

cvs diff: internal error: bad date 1 Jan 1970 00:00:00 -0000
===================================================================
RCS file: mdbase/Makefile.in
diff -N mdbase/Makefile.in
cvs [diff aborted]: internal error: no revision information for 1.4

OR

cvs diff: warning: duplicate key `char' in RCS file 
`/cm/REPOSITORY/PROJNAME/keyboard/kbd_unix.c,v'
cvs diff: warning: duplicate key `/*' in RCS file 
`/cm/REPOSITORY/PROJNAME/keyboard/kbd_unix.c,v'
cvs diff: warning: duplicate key `int' in RCS file 
`/cm/REPOSITORY/PROJNAME/keyboard/kbd_unix.c,v'
{the rest of the contents of the file}
cvs [diff aborted]: EOF in value in RCS file 
/cm/REPOSITORY/PROJNAME/keyboard/kbd_unix.c,v

OR

Terminated with fatal signal 11

I got a core and backtrace from this one after it ran in ext mode.
#0  0xef6a49d0 in strncmp () from /usr/lib/libc.so.1
#1  0x466b8 in RCS_reparsercsfile (rdata=0xd9588, pfp=0x0, rcsbufp=0x0)
    at rcs.c:537
#2  0x4997c in RCS_isdead (rcs=0xd9588, tag=0x379e98 "1.17") at rcs.c:3423
#3  0x20cbc in Classify_File (finfo=0xefffeeb8, tag=0x0, date=0x0, 
    options=0x0, force_tag_match=1, aflag=0, versp=0xefffebdc, pipeout=0)
    at classify.c:75
#4  0x60b44 in update_fileproc (callerdat=0xaf800, finfo=0xefffeeb8)
    at update.c:587
#5  0x52008 in do_file_proc (p=0x1ed750, closure=0xefffee78) at recurse.c:826
#6  0x33d0c in walklist (list=0xd4880, proc=0x51f08 <do_file_proc>, 
    closure=0xefffee78) at hash.c:370
#7  0x51e04 in do_recursion (frame=0xefffefb0) at recurse.c:730
#8  0x52560 in do_dir_proc (p=0x0, closure=0xeffff0d8) at recurse.c:1090
#9  0x33d0c in walklist (list=0xcd7d0, proc=0x5202c <do_dir_proc>, 
    closure=0xeffff0d8) at hash.c:370
#10 0x51ebc in do_recursion (frame=0xeffff250) at recurse.c:757
#11 0x52560 in do_dir_proc (p=0x0, closure=0xeffff378) at recurse.c:1090
#12 0x33d0c in walklist (list=0xcd4d8, proc=0x5202c <do_dir_proc>, 
    closure=0xeffff378) at hash.c:370
#13 0x51ebc in do_recursion (frame=0xeffff4b0) at recurse.c:757
#14 0x5191c in start_recursion (fileproc=0, 
    filesdoneproc=0x6107c <update_filesdone_proc>, 
    direntproc=0x611a0 <update_dirent_proc>, 
    dirleaveproc=0x6150c <update_dirleave_proc>, callerdat=0x0, argc=0, 
    argv=0xce030, local=0, which=3, aflag=0, readlock=1, 
    update_preload=0xce010 "PROJNAME", dosrcs=1) at recurse.c:354
#15 0x60abc in do_update (argc=0, argv=0x0, xoptions=0x0, xtag=0x0, xdate=0x0, 
    xforce=1, local=0, xbuild=1, xaflag=0, xprune=0, xpipeout=0, which=3, 
    xjoin_rev1=0x0, xjoin_rev2=0x0, preload_update_dir=0xce010 "PROJNAME", 
    xdotemplate=1) at update.c:505
#16 0x20998 in checkout_proc (argc=1, argv=0xcdff0, where_orig=0x0, 
    mwhere=0x0, mfile=0x0, shorten=729168, local_specified=0, 
    omodule=0xb1b60 "PROJNAME", msg=0x84978 "Updating") at checkout.c:1142
#17 0x41c58 in do_module (db=0xb5a48, mname=0xb1b60 "PROJNAME", 
m_type=CHECKOUT, 
    msg=0x84978 "Updating", callback_proc=0x1fcbc <checkout_proc>, where=0x0, 
    shorten=0, local_specified=0, run_module_prog=1, build_dirs=1, 
    extra_arg=0x0) at modules.c:299
#18 0x1f800 in checkout (argc=1, argv=0xb5a68) at checkout.c:384
#19 0x58580 in do_cvs_command (cmd_name=0x967f0 "checkout", 
    command=0x1efbc <checkout>) at server.c:2794
#20 0x59d1c in serve_co (arg=0xcb16a "") at server.c:3900
#21 0x5b68c in server (argc=718772, argv=0xaf400) at server.c:5258
#22 0x40588 in main (argc=1, argv=0xeffffdf0) at main.c:989



running contrib/check_cvs, with the cvs-1.11.9 binary in the path, caused a 
segfault with core (of cvs) & backtrace as follows:

#0  0xef5a49d0 in strncmp () from /usr/lib/libc.so.1
#1  0x46304 in RCS_reparsercsfile (rdata=0xb5fa0, pfp=0x0, rcsbufp=0x0)
    at rcs.c:586
#2  0x480f4 in RCS_gettag (rcs=0xb5fa0, symtag=0xbcc98 "1.1.1.1", 
    force_tag_match=1, simple_tag=0xefffeec4) at rcs.c:2394
#3  0x47e5c in RCS_getversion (rcs=0xb5fa0, tag=0xbcc98 "1.1.1.1", date=0x0, 
    force_tag_match=1, simple_tag=0xefffeec4) at rcs.c:2266
#4  0x63988 in Version_TS (finfo=0xeffff2d8, options=0x0, 
    tag=0xeffffb50 "1.1.1.1", date=0x0, force_tag_match=1, set_time=0)
    at vers_ts.c:180
#5  0x20fa8 in Classify_File (finfo=0xeffff2d8, tag=0xeffffb50 "1.1.1.1", 
    date=0x0, options=0x0, force_tag_match=1, aflag=0, versp=0xefffeffc, 
    pipeout=1) at classify.c:38
#6  0x608c8 in update_fileproc (callerdat=0xaf400, finfo=0xeffff2d8)
    at update.c:591
#7  0x51d3c in do_file_proc (p=0xbbf78, closure=0xeffff298) at recurse.c:832
#8  0x33828 in walklist (list=0xbbf50, proc=0x51c3c <do_file_proc>, 
    closure=0xeffff298) at hash.c:370
#9  0x51b38 in do_recursion (frame=0xeffff4b0) at recurse.c:736
#10 0x52524 in unroll_files_proc (p=0xbbf00, closure=0xeffff4b0)
    at recurse.c:1209
#11 0x33828 in walklist (list=0xbbed8, proc=0x52408 <unroll_files_proc>, 
    closure=0xeffff4b0) at hash.c:370
#12 0x51618 in start_recursion (fileproc=0, filesdoneproc=0xbcc58, 
    direntproc=0xb8c10, dirleaveproc=0xb8c28, callerdat=0x4, argc=1, 
    argv=0xbcc48, local=0, which=6, aflag=0, locktype=1, 
    update_preload=0xb8bc8 "PROJNAME/tsd/build", dosrcs=1) at recurse.c:347
#13 0x60840 in do_update (argc=1, argv=0xbcc3c, xoptions=0x0, 
    xtag=0xeffffb50 "1.1.1.1", xdate=0x0, xforce=1, local=0, xbuild=1, 
    xaflag=0, xprune=1, xpipeout=1, which=6, xjoin_rev1=0x0, xjoin_rev2=0x0, 
    preload_update_dir=0xb8bc8 "PROJNAME/tsd/build", xdotemplate=1) at 
update.c:509
#14 0x20d80 in checkout_proc (argc=2, argv=0xbcc38, where_orig=0x0, 
    mwhere=0x0, mfile=0x0, shorten=724992, local_specified=0, 
    omodule=0xeffffb58 "PROJNAME/tsd/build/XXXsiz.h", msg=0x84970 "Updating")
    at checkout.c:1136
#15 0x41a38 in do_module (db=0xb3f40, 
    mname=0xeffffb58 "PROJNAME/tsd/build/XXXsiz.h", m_type=CHECKOUT, 
    msg=0x84970 "Updating", callback_proc=0x200a4 <checkout_proc>, where=0x0, 
    shorten=0, local_specified=0, run_module_prog=0, build_dirs=0, 
    extra_arg=0x0) at modules.c:297
#16 0x1fbe0 in checkout (argc=1, argv=0xeffffa4c) at checkout.c:377
#17 0x4034c in main (argc=6, argv=0xeffffa38) at main.c:994




>How-To-Repeat:
        the following command would give me the error(s) at least once per run
        `cvs diff;cvs diff;cvs diff`
>Fix:
        back out to cvs-1.11.1P1


-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter