bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

stack trace for cvs segmentation fault. RE cvs repository in a ba d stat


From: Ryan Grow
Subject: stack trace for cvs segmentation fault. RE cvs repository in a ba d state, and cvs seg faults on export of pr
Date: Wed, 2 May 2001 09:21:24 -0600

I am sending this stack trace in regards to my message that Larry replied to
on cvs-info. First I include the stack trace, followed by the copy of
Larry's response to my message that describes the problem.


The versions of the software are as follows:

[rgrow@devtools1 stage]$ cvs version
Concurrent Versions System (CVS) 1.11 (client/server)
[rgrow@devtools1 stage]$ uname -a
Linux devtools1 2.2.16-22 #1 Tue Aug 22 16:49:06 EDT 2000 i686 unknown
[rgrow@devtools1 stage]$

The following output I have included is from running the program in gdb. I
have abbreviated the list of filenames in the output and replace with
ellipses(...).


(gdb) run -q export -N -D tomorrow web_reports
Starting program: /usr/bin/cvs -q export -N -D tomorrow web_reports
U web_reports/docs/20010124_Functional_Specification.doc
... ( a lot of files ommitted from the listing )
U web_reports/htdocs/query/query_validate_email.cfm

Program received signal SIGSEGV, Segmentation fault.
0x80740c5 in strcpy () at ../sysdeps/generic/strcpy.c:31
31      ../sysdeps/generic/strcpy.c: No such file or directory.


-------
One thing to note, the problem I am having is with files in the
web_reports/htdocs/report directory. This is where we attempted to rename
files with leading upper case and ran into problems. It seems likely that
this is the directory where cvs is crashing. Also, another note, cvs
checkout, update, commit, etc. all work without a fault on this project. (
except for the 'no nothing about' error messages described below.)
-----------
Here is the full traceback output from gdb:


#0  0x80740c5 in strcpy () at ../sysdeps/generic/strcpy.c:31
#1  0x80ed9a0 in ?? ()
#2  0x8073158 in strcpy () at ../sysdeps/generic/strcpy.c:31
#3  0x808dc46 in strcpy () at ../sysdeps/generic/strcpy.c:31
#4  0x8050067 in strcpy () at ../sysdeps/generic/strcpy.c:31
#5  0x8089635 in strcpy () at ../sysdeps/generic/strcpy.c:31
#6  0x807c698 in strcpy () at ../sysdeps/generic/strcpy.c:31
#7  0x80603ba in strcpy () at ../sysdeps/generic/strcpy.c:31
#8  0x807c47f in strcpy () at ../sysdeps/generic/strcpy.c:31
#9  0x807cc65 in strcpy () at ../sysdeps/generic/strcpy.c:31
#10 0x80603ba in strcpy () at ../sysdeps/generic/strcpy.c:31
#11 0x807c507 in strcpy () at ../sysdeps/generic/strcpy.c:31
#12 0x807cc65 in strcpy () at ../sysdeps/generic/strcpy.c:31
#13 0x80603ba in strcpy () at ../sysdeps/generic/strcpy.c:31
#14 0x807c507 in strcpy () at ../sysdeps/generic/strcpy.c:31
#15 0x807cc65 in strcpy () at ../sysdeps/generic/strcpy.c:31
#16 0x80603ba in strcpy () at ../sysdeps/generic/strcpy.c:31
#17 0x807c507 in strcpy () at ../sysdeps/generic/strcpy.c:31
#18 0x807c05d in strcpy () at ../sysdeps/generic/strcpy.c:31
#19 0x80895b9 in strcpy () at ../sysdeps/generic/strcpy.c:31
#20 0x804fe32 in strcpy () at ../sysdeps/generic/strcpy.c:31
#21 0x806d17f in strcpy () at ../sysdeps/generic/strcpy.c:31
#22 0x804ec8e in strcpy () at ../sysdeps/generic/strcpy.c:31
#23 0x806bc36 in strcpy () at ../sysdeps/generic/strcpy.c:31
#24 0x4006cb65 in __libc_start_main (main=0x806b19c <strcpy+134328>, argc=7,
ubp_av=0xbffffa94, init=0x8049c14,
    fini=0x80a8c7c <regfree+69024>, rtld_fini=0x4000df24 <_dl_fini>,
stack_end=0xbffffa8c)
    at ../sysdeps/generic/libc-start.c:111

And here is the original message that describes the problem.....

-----Original Message-----
From: larry.jones@sdrc.com [mailto:larry.jones@sdrc.com]
Sent: Wednesday, May 02, 2001 8:49 AM
To: rgrow@Dbdoctor.net
Cc: info-cvs@gnu.org
Subject: Re: cvs repository in a bad state, and cvs seg faults on export
of pr


Ryan Grow writes:
> 
> We are having problems with one of our working areas. The developer told
me
> that he tried to rename several files from being lower case to having a
> leading upper case letter.

This currently doesn't work on case preserving but case insensitive
systems (i.e., Windows).  CVS was originally designed to be case
sensitive and, although it tries to handle case insensitive systems, it
doesn't quite handle this case correctly.

> He told me that he removed the files with the cvs remove and commit
> commands. But then when he attempted to add the new files with the new
name,
> he got the following failure message:
> 
> cvs commit -m "" Threats_warnings_completion.cfm
> cvs commit: [14:29:51] waiting for rgrow's lock in
> /usr/local/cvsroot/web_reports/htdocs/reports

Not initially -- that's a result of the crash you mention later.  The
original error message should have been something like "cannot add file
when RCS file already exists".

> Another symptom, is when I do a cvs update in the working area of this
> project, I see several lines of messages like this:
> 
> cvs update: nothing known about htdocs/reports/Physical_IO_statistics.cfm
> 
> This is the name of the file that he had intended to add.

That's another symptom of the case sensitivity difficulties -- CVS
sort-of knows about the file (because there's a file in the repository
with the same name if you ignore case differences), but doesn't really
know about it (because of the case differences).

> Another symptom is that cvs will seg fault when I try to export this
> project. It progresses the export until it gets to the directory
containing
> the files in question, at which point it seg faults. This happens if I run
> the cvs client on linux. If I run it on windows, it crashes in the same
> place with the message: 'Terminated with fatal signal 11'.

If you know how to use a debugger to get a traceback from the crash,
please send it to bug-cvs@gnu.org so we can track down and fix the
problem.

> I'd appreciate any advice on how to restore the repository to a clean
state
> from this locking problem.

You'll need to remove the stale lock files by hand.  See:

http://cvshome.org/docs/manual/cvs_10.html#SEC88

After that, I think your only option is to manually rename the
repository files (which is less than desirable since you lose the
previous spelling of the name).

-Larry Jones

I keep forgetting that rules are only for little nice people. -- Calvin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]