info-cvs
[Top][All Lists]
Advanced

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

Re: "cvs ls" and "cvs rls" cause Segmentation fault


From: Mark Novak
Subject: Re: "cvs ls" and "cvs rls" cause Segmentation fault
Date: Sun, 17 Sep 2006 17:41:57 -0700

One more point that I just discovered: The warning that validate_repo generates with cvs-1.12.12-19 is also reported with cvs-1.12.13. I rebuilt the repository locally from scratch with 1.12.13, and got this when I ran validate_repo:

address@hidden:/tmp/cvs-1.12.13/contrib> validate_repo -d /home/mark/cvsroot
Couldn't read date/author/state for revision 1.1
of CVSROOT/verifymsg from `cvs rlog'.
line = date: 2006-09-17 16:37:06 -0700; author: mark; state: Exp; commitid: kMy57GY58RTlReNr;

Apparently this issue is not directly related to the seg fault.

Mark


From: "Mark Novak" <address@hidden>
To: address@hidden
CC: address@hidden
Subject: Re: "cvs ls" and "cvs rls" cause Segmentation fault
Date: Sun, 17 Sep 2006 13:20:46 -0700

Hi Mark,
You are correct that NFS was not the problem. I rebuilt the CVS repository completely local to micron and the problem still exists with cvs-1.12.12-19. However, using your cvs-1.12.13 build fixed the problem.

The validate_repo command did point out corruption:

address@hidden:~/temp> /tmp/cvs-1.12.13/contrib/validate_repo -d /fast/home/mark/cvsroot --verbose
Verbose Mode Turned On
Processing: /fast/home/mark/cvsroot
Examining `CVSROOT/verifymsg,v'
Couldn't read date/author/state for revision 1.1
of CVSROOT/verifymsg from `cvs rlog'.
line = date: 2006-09-14 08:30:27 -0700; author: mark; state: Exp; commitid: 540d4509758f4567;

Note that this does not appear to be an NFS related issue, since I get similar output on the local repository:

address@hidden:~/cvsroot> /tmp/cvs-1.12.13/contrib/validate_repo -d /home/mark/cvsroot --verbose
Verbose Mode Turned On
Processing: /home/mark/cvsroot
Examining `CVSROOT/verifymsg,v'
Couldn't read date/author/state for revision 1.1
of CVSROOT/verifymsg from `cvs rlog'.
line = date: 2006-09-17 13:00:00 -0700; author: mark; state: Exp; commitid: 2c37450da9404567;

This repository was generated by running cvs init and checking in the files, not by copying the remote repository to the local area, so it should have been clean.

It looks like I'll be using your cvs-1.12.13 version from now on. I can rebuild the repository from scratch and use a different transport method.

Thank you very much for your help.

Mark


From: "Mark D. Baushke" <address@hidden>
To: "Mark Novak" <address@hidden>
CC: address@hidden
Subject: Re: "cvs ls" and "cvs rls" cause Segmentation fault
Date: Sun, 17 Sep 2006 09:09:45 -0700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Novak <address@hidden> writes:

> Thank you for your reply and useful suggestions.  I am running CVS in
> client/server mode where my server is running on another machine that I
> access via NFS as a local directory. The machine I am using is micron and
> the CVS repository is on fast in directory /fast/home/mark/cvsroot as
> visible from micron.

Your command output shows that you are running in :local: mode rather
than :pserver: or :ext: mode, so you are not using the client/server
code path.

Note: Mounting your repository via NFS is NOT a recommended practice. We
have had more reports of repository corruptions via NFS than any other
single method.

>
> Here is the output from running cvs -ttt:

.....

>
> address@hidden:~/temp/sockets> cvs -ttt ls
>   -> main: Session ID is 1fac450cafad4567
>   -> Name_Root ((null), (null))
>   -> parse_cvsroot (/fast/home/mark/cvsroot)
>   -> walklist ( list=0x80defe8, proc=0x8078010, closure=(nil) )
>   -> main loop with CVSROOT=/fast/home/mark/cvsroot
>   -> parse_config (/fast/home/mark/cvsroot)

.....

> Segmentation fault
>
> I am running cvs-1.12.12-19 built for i586 and it is running on a P4. The
> reporsitory is residing on an Athlon machine, but that shouldn't make any
> difference.

True, you only need to worry about the local cvs executable if you are
using :local: mode.

> As for wading through the core dump, I'm pretty green at this. I followed
> the procedure you described and get this output:
>
> address@hidden:~/temp/sockets> gdb /usr/bin/cvs core
> GNU gdb 6.4
.....
> (no debugging symbols found)

This makes it harder to debug your problem as there appear to be no
debugging symbols.

> Core was generated by `cvs -ttt ls'.
> Program terminated with signal 11, Segmentation fault.

.....

> (gdb) bt
> #0  0x08068979 in error ()
> #1  0x080688a5 in error ()
> #2  0x08068901 in error ()
> #3  0x08068988 in error ()
> #4  0x08076f39 in error ()
> #5  0x08077366 in error ()
> #6  0x08078c83 in error ()
> #7  0xb7d8587c in __libc_start_main () from /lib/libc.so.6
> #8  0x0804b2f1 in ?? ()
> (gdb)
>
> I can't make head or tail of this... But I hope it might make some sense to
> you.

Something got very lost trying to print an error for you, there is not
enough information for me to really know what happened.

> I hope this gives you some more useful information so that you may
> advise me further.

Advice 1: Do not use NFS to access your repository (this is unlikely to
be the root cause of your current problem, but it will bite you
eventually).

Advice 2: Fetch a pristine copy of cvs from
    ftp://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.12/cvs-1.12.12.tar.gz
    (if you want to try the same release to see if it matters)
or
    ftp://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.13/cvs-1.12.13.tar.gz

Fetch it, unpack it, configure it, build it, try it:

   cd /tmp
wget ftp://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.13/cvs-1.12.13.tar.gz
   tar xzf cvs-1.12.13.tar.gz
   cd cvs-1.12.13
   ./configure
   make
   src/cvs -d /fast/home/mark/cvsroot rls
   cd ~/temp/sockets
   /tmp/cvs-1.12.13/src/cvs ls

Does this work better for you?

If not, then a core dump should be more useful with one you build yourself
as it will have debugging symbols enabled by default and the gdb backtrace
might help us determine the real problem.

Note that now that you have built cvs-1.12.13, you should probably run
the command:

   /tmp/cvs-1.12.13/contrib/validate_repo -d /fast/home/mark/cvsroot

to see if there are any corruptions due to NFS usage. If there are, then
you will need to take a closer look at any files that are identified. You
may get additional information if you run with --verbose (-v)

   /tmp/cvs-1.12.13/contrib/validate_repo -v -d /fast/home/mark/cvsroot

I hope this helps.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFFDXNICg7APGsDnFERAhU8AKDwHTRh6SMG6xoA74Wm5HKMpnSCRwCeJwlt
TVcGqu8mDpkPD5oQvqP4OxQ=
=Q56I
-----END PGP SIGNATURE-----




_______________________________________________
info-cvs mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/info-cvs






reply via email to

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