Bug 63365 - "cvs rdiff -D" segmentation fault
Summary: "cvs rdiff -D" segmentation fault
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: cvs
Version: 7.1
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-12 23:20 UTC by Mark Harig
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-03-17 10:39:47 UTC
Embargoed:


Attachments (Terms of Use)

Description Mark Harig 2002-04-12 23:20:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
cvs rdiff generates a segmentation fault when provided '-D' options.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Login to bash as an ordinary user
2. Set CVSROOT to point to the cvs repository, and export it
3. Run the command: $ cvs rdiff -Dyesterday -Dtoday <module>
where <module> is the name of a module in your cvs repository.
	

Actual Results:  cvs rdiff generates a segmentation fault, and a corresponding 
core file.  I have deleted and regenerated the core file more than five times.  
Changing the date format provided to the '-D' option does not help.

Expected Results:  I expected a listing of the differences of the files that 
had changed since yesterday.

Additional info:

here is the stack dump from gdb.  I rebuilt cvs to provide some debug 
information.  this problem also occurs with the cvs binary provided by redhat's 
cvs rpm (version 1.11.1p1, release 7).

I have the latest glibc rpm (2.2.4, release 24) from redhat installed.

$ gdb /usr/local/bin/cvs-1.11.1p1 core
GNU gdb Red Hat Linux (5.1-0.71)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/bin/cvs-1.11.1p1 rdiff -s -Dyesterday -Dtoday 
iDirect'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /usr/kerberos/lib/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/kerberos/lib/libgssapi_krb5.so.2
Reading symbols from /usr/kerberos/lib/libkrb5.so.3...done.
Loaded symbols for /usr/kerberos/lib/libkrb5.so.3
Reading symbols from /usr/kerberos/lib/libk5crypto.so.3...done.
Loaded symbols for /usr/kerberos/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /usr/kerberos/lib/libcom_err.so.3...done.
Loaded symbols for /usr/kerberos/lib/libcom_err.so.3
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x08075320 in RCS_getdate (rcs=0x80d87b0, 
    date=0x80d0f28 "2002.04.12.22.10.33", force_tag_match=1) at rcs.c:2898
2898        if (!force_tag_match || RCS_datecmp (vers->date, date) <= 0)
(gdb) bt
#0  0x08075320 in RCS_getdate (rcs=0x80d87b0, 
    date=0x80d0f28 "2002.04.12.22.10.33", force_tag_match=1) at rcs.c:2898
#1  0x08071546 in patch_fileproc (callerdat=0x0, finfo=0xbffff200)
    at patch.c:415
#2  0x0807d616 in do_file_proc (p=0x80db328, closure=0xbffff1f0)
    at recurse.c:823
#3  0x0806260e in walklist (list=0x80dd828, proc=0x807d538 <do_file_proc>, 
    closure=0xbffff1f0) at hash.c:370
#4  0x0807d452 in do_recursion (frame=0xbffff290) at recurse.c:727
#5  0x0807db18 in do_dir_proc (p=0x80dbf48, closure=0xbffff338)
    at recurse.c:1087
#6  0x0806260e in walklist (list=0x80d4038, proc=0x807d63c <do_dir_proc>, 
    closure=0xbffff338) at hash.c:370
#7  0x0807d4e0 in do_recursion (frame=0xbffff3e0) at recurse.c:754
#8  0x0807db18 in do_dir_proc (p=0x80d3f50, closure=0xbffff488)
    at recurse.c:1087
#9  0x0806260e in walklist (list=0x80d3690, proc=0x807d63c <do_dir_proc>, 
    closure=0xbffff488) at hash.c:370
#10 0x0807d4e0 in do_recursion (frame=0xbffff530) at recurse.c:754
#11 0x0807db18 in do_dir_proc (p=0x80d4e00, closure=0xbffff5d8)
    at recurse.c:1087
#12 0x0806260e in walklist (list=0x80d38f8, proc=0x807d63c <do_dir_proc>, 
    closure=0xbffff5d8) at hash.c:370
#13 0x0807d4e0 in do_recursion (frame=0xbffff680) at recurse.c:754
#14 0x0807db18 in do_dir_proc (p=0x80d0fa0, closure=0xbffff728)
    at recurse.c:1087
#15 0x0806260e in walklist (list=0x80d1418, proc=0x807d63c <do_dir_proc>, 
    closure=0xbffff728) at hash.c:370
#16 0x0807d4e0 in do_recursion (frame=0xbffff7c0) at recurse.c:754
#17 0x0807cfe6 in start_recursion (fileproc=0x8071480 <patch_fileproc>, 
    filesdoneproc=0, direntproc=0x8072140 <patch_dirproc>, dirleaveproc=0, 
    callerdat=0x0, argc=0, argv=0x80d1058, local=0, which=6, aflag=0, 
    readlock=1, update_preload=0x80d1048 "iDirect", dosrcs=1) at recurse.c:351
#18 0x08071466 in patch_proc (argc=1, argv=0x80d1000, xwhere=0x0, mwhere=0x0, 
    mfile=0x0, shorten=0, local_specified=0, mname=0x80d0c50 "iDirect", 
    msg=0x80b93a2 "Patching") at patch.c:356
#19 0x0806e917 in do_module (db=0x80d1140, mname=0x80d0c50 "iDirect", 
    m_type=PATCH, msg=0x80b93a2 "Patching", 
    callback_proc=0x80711a0 <patch_proc>, where=0x0, shorten=0, 
    local_specified=0, run_module_prog=0, build_dirs=0, extra_arg=0x0)
    at modules.c:299
#20 0x0807116d in patch (argc=5, argv=0x80d0be0) at patch.c:255
#21 0x0806d604 in main (argc=5, argv=0x80d0bd0) at main.c:987
#22 0x40102647 in __libc_start_main (main=0x806cb60 <main>, argc=6, 
    ubp_av=0xbffffa64, init=0x804a29c <_init>, fini=0x80a7480 <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffa5c)
    at ../sysdeps/generic/libc-start.c:129
(gdb)

Comment 1 Mark Harig 2002-04-15 18:57:34 UTC
Here is some additional information about what is causing CVS to generate the 
segmentation fault.

I found the following ill-formed repository file, "Makefile,v" in one of the 
directories in my CVS repository:

> head     ;
> access   ;
> symbols  ;
> locks    ; strict;
> comment  @# @;
>
>
> desc
> @@
>
>
>

After I removed this file, the "cvs rdiff" command completed successfully.  Of 
course, generating a segmentation fault is not a good method to report this 
invalid file format.

The short-term workaround for this bug is to:

  1) search your CVS repository for the core file, finding the directory in 
which it was written.

  2) check the format of the files in that directory using "cvs update".  
update responds with the message:

     cvs update: nothing known about <your broken file>

  3) remove the corresponding ",v" file from the repository.

  4) repeat until all invalid ",v" files have been removed from the repository.

The "cvs rdiff" command should then run to completion without any errors.




Note You need to log in before you can comment on or make changes to this bug.