[Top][All Lists]

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

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

From: Mark D. Baushke
Subject: Re: "cvs ls" and "cvs rls" cause Segmentation fault
Date: Sun, 17 Sep 2006 09:09:45 -0700

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/
> #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

Advice 2: Fetch a pristine copy of cvs from
    (if you want to try the same release to see if it matters)

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

   cd /tmp
   tar xzf cvs-1.12.13.tar.gz
   cd cvs-1.12.13
   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
Version: GnuPG v1.4.4 (FreeBSD)


reply via email to

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