From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 03:47:19 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E0F37B401 for ; Wed, 23 Jul 2003 03:47:19 -0700 (PDT) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E040243FA3 for ; Wed, 23 Jul 2003 03:47:17 -0700 (PDT) (envelope-from scott@fishballoon.org) Received: from llama.fishballoon.org ([81.104.195.199]) by mta03-svc.ntlworld.comESMTP <20030723104716.QUEB2652.mta03-svc.ntlworld.com@llama.fishballoon.org>; Wed, 23 Jul 2003 11:47:16 +0100 Received: from scott by llama.fishballoon.org with local (Exim 4.20) id 19fH8h-00039C-U6; Wed, 23 Jul 2003 11:46:31 +0100 Date: Wed, 23 Jul 2003 11:46:31 +0100 From: Scott Mitchell To: freebsd-stable@freebsd.org Message-ID: <20030723104631.GA11861@llama.fishballoon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.8-RELEASE i386 Sender: Scott Mitchell Subject: cvs pserver sig11 on 4.8-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 10:47:19 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, We recently moved our CVS repository from a 4.6-STABLE machine to a brand new 4.8 install, on another identical machine. The server runs cvs in 'pserver' mode, for remote access by various Windows/Solaris/Linux/FreeBSD clients. We pretty soon noticed that the cvs server process was occasionally crashing on sig11 (ie. a segfault). The only evidence for this was in the message log, the cvs operations always completed normally on the client side. This *never* happened on the old server, so I figured it had to be a hardware problem on the new machine, or some issue with 4.8. Probably happening about 1 in every 100 times the cvs server was run. I compiled a debug version of cvs from the 4.8 sources and was able to get a few cores, once I figured out how to make it actually dump core. I've attached the log of a gdb session on one of these -- all the cores I have show the process crashing in the same place, where it's clearly trying to follow a NULL pointer. I've since copied the cvs binary from the 4.6 machine across to the new server -- we've run with this for the past two weeks and had exactly zero problems with it. Given that all the cores are the same, and that the only thing we've seen fail on this machine is the 4.8 cvs code, this smells like a cvs bug to me. I've no idea if it's in our local extensions or the base cvs code -- should I be sending the bug report to FreeBSD.org or cvshome.org? Is there anyone on here familiar with the internals of cvs who wants to take a look at this? I can provide any additional configuration details or more grovelling in the core dumps on request... Cheers, Scott --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gdb.log" Content-Transfer-Encoding: quoted-printable Script started on Wed Jul 23 11:14:55 2003 pukeko# gdb `which cvs.debug` cvs.debug.81697.core=0D=0D GNU gdb 4.18 (FreeBSD)=0D Copyright 1998 Free Software Foundation, Inc.=0D GDB is free software, covered by the GNU General Public License, and you ar= e=0D welcome to change it and/or distribute copies of it under certain condition= s.=0D Type "show copying" to see the conditions.=0D There is absolutely no warranty for GDB. Type "show warranty" for details.= =0D This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read cal= led at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxrea= d.c line 2627 in elfstab_build_psymtabs=0D Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../..= /contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf=0D =0D Core was generated by `cvs.debug'.=0D Program terminated with signal 11, Segmentation fault.=0D Reading symbols from /usr/lib/libgnuregex.so.2...done.=0D Reading symbols from /usr/lib/libmd.so.2...done.=0D Reading symbols from /usr/lib/libcrypt.so.2...done.=0D Reading symbols from /usr/lib/libz.so.2...done.=0D Reading symbols from /usr/lib/libc.so.4...done.=0D Reading symbols from /usr/libexec/ld-elf.so.1...done.=0D #0 buf_shutdown (buf=3D0x0)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/buffer.c:12= 08=0D 1208 if (buf->shutdown)=0D (gdb) where=0D #0 buf_shutdown (buf=3D0x0)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/buffer.c:12= 08=0D #1 0x8087e2b in server_cleanup (sig=3D0)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/server.c:48= 92=0D #2 0x805ec67 in error_exit ()=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/error.c:71= =0D #3 0x805ef27 in error (status=3D1, errnum=3D0, =0D message=3D0x80ab4b9 "received %s signal")=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/error.c:212= =0D #4 0x806daae in main_cleanup (sig=3D13)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/main.c:395= =0D #5 0x80926e4 in strip_trailing_slashes ()=0D #6 0xbfbfffac in ?? ()=0D #7 0x804d85a in buf_send_output (buf=3D0x80c1040)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/buffer.c:28= 7=0D #8 0x804d900 in buf_flush (buf=3D0x80c1040, block=3D1)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/buffer.c:35= 2=0D #9 0x8087eb7 in server_cleanup (sig=3D0)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/server.c:50= 07=0D #10 0x80883e2 in server (argc=3D1, argv=3D0xbfbffc88)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/server.c:52= 34=0D #11 0x806e636 in main (argc=3D1, argv=3D0xbfbffc88)=0D at /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/main.c:1028= =0D #12 0x804a67a in _start ()=0D (gdb) list=0D 1203 =0D 1204 int=0D 1205 buf_shutdown (buf)=0D 1206 struct buffer *buf;=0D 1207 {=0D 1208 if (buf->shutdown)=0D 1209 return (*buf->shutdown) (buf);=0D 1210 return 0;=0D 1211 }=0D 1212 =0D (gdb) quit=0D pukeko# ^D=08=08exit=0D Script done on Wed Jul 23 11:15:28 2003 --qDbXVdCdHGoSgWSk--