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

[Mark Novak]

Hi Mark,
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.

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)
 -> new_config ()
 -> parse_info() examining line: `UseNewInfoFmtStrings=yes'
 -> readBool (/fast/home/mark/cvsroot/CVSROOT/config, UseNewInfoFmtStrings, 
yes)
 -> Read 0 for UseNewInfoFmtStrings
 -> start_recursion ( fileproc=0x8077cc0, filesdoneproc=(nil),
                      direntproc=0x80779d0, dirleavproc=0x80778e0,
                      callerdat=0x80df278, argc=0, argv=(nil),
                      local=0, which=3, aflag=0,
                      locktype=1, update_preload=(null)
                      dosrcs=1, repository_in=(null) )
 -> do_recursion ( frame=bf9a8d88 )
 -> Name_Root ((null), )
 -> parse_cvsroot (/fast/home/mark/cvsroot)
 -> walklist ( list=0x80df4f0, proc=0x808e050, closure=0xbf9a8ce8 )
 -> Name_Root (., .)
 -> parse_cvsroot (/fast/home/mark/cvsroot)
 -> do_recursion ( frame=bf9a8c28 )
 -> Name_Root ((null), )
 -> parse_cvsroot (/fast/home/mark/cvsroot)
 -> walklist ( list=0x80dfe50, proc=0x8067d90, closure=0x80dfbe8 )
 -> walklist ( list=0x80dfe50, proc=0x8067d20, closure=0x80e12d8 )
 -> Reader_Lock(/fast/home/mark/cvsroot/sockets)
 -> set_lock (/fast/home/mark/cvsroot/sockets, 1)
 -> lock_name (/fast/home/mark/cvsroot/sockets, #cvs.lock)
 -> lock_name (/fast/home/mark/cvsroot/sockets, #cvs.rfl.micron.8108)
 -> walklist ( list=0x80dfbe8, proc=0x808d780, closure=0xbf9a8bc0 )
 -> Simple_Lock_Cleanup()
 -> remove_lock_files (/fast/home/mark/cvsroot/sockets)
 -> walklist ( list=0x80e12d8, proc=0x808e050, closure=0xbf9a8bb8 )
 -> Leaving do_recursion (frame=bf9a8c28)
 -> Leaving do_recursion (frame=bf9a8d88)
 -> walklist ( list=0x80df278, proc=0x8077770, closure=(nil) )
 -> walklist ( list=0x80df888, proc=0x8077850, closure=(nil) )
ClientSocket.cpp
ClientSocket.h
Makefile
Makefile.aimk
ServerSocket.cpp
ServerSocket.h
Socket.cpp
Socket.h
SocketException.h
master.cc
messages.h
simple_client_main.cpp
simple_server_main.cpp
slave.cc
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.

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
Copyright 2005 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 "i586-suse-linux"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(no debugging symbols found)
Core was generated by `cvs -ttt ls'.
Program terminated with signal 11, Segmentation fault.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /lib/libc.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x08068979 in error ()
(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.

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

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: Thu, 14 Sep 2006 22:07:22 -0700

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

Mark Novak <address@hidden> writes:

> Whenever I execute a cvs ls or cvs rls command I get a Segmentation
> fault, like this:
>
> address@hidden:~/pvm3/sockets> cvs ls
> ClientSocket.cpp
> ClientSocket.h
> Makefile
> Makefile.aimk
> ServerSocket.cpp
> ServerSocket.h
> Socket.cpp
> Socket.h
> SocketException.h
> master.cc
> messages.h
> simple_client_main.cpp
> simple_server_main.cpp
> slave.cc
> Segmentation fault
>
> address@hidden:~/pvm3/sockets> cvs rls
> cvs rls: Listing module: `.'
> CVSROOT
> sockets
> Segmentation fault
>
> It appears that all the files are listed before the Segmentation
> fault.  This only seems to happen after I've committed changes beyond
> the initial import.  I've rebuilt the CVS database twice and the
> problem appears the same both times. I'm running CVS 1.12.12 on Suse
> 10.1. If anybody has a clue as to what's causing this I'd be glad to
> hear it.

Are you in client/server mode? What method of transport :ext: or
something else? Have you tried 'cvs -ttt ls' to have cvs tell you what
it is doing?

You have provided very little useful information ... the Novell folks
have patches of their own against cvs 1.12.12. Do you have
cvs-1.12.12-19 or some other release? What hardware is your host?
i386? x64_86? ppc?

Have you tried to debug the problem? Do something like 'ulimit -c unlimited'
and when you have the core dump do a 'gdb /usr/bin/cvs core' and at the
(gdb) prompt do a 'bt' command to figure out where the crash is happening?

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

iD8DBQFFCjUJCg7APGsDnFERAq/kAKCP0quIE2//j8Hbnxm+E7Itb2WUPwCgkxqH
AJi+FfsAKckPnviSbediWSk=
=Q/F2
-----END PGP SIGNATURE-----