From owner-freebsd-current@FreeBSD.ORG Mon Dec 7 14:34:22 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB989106568F for ; Mon, 7 Dec 2009 14:34:22 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id 5302E8FC08 for ; Mon, 7 Dec 2009 14:34:22 +0000 (UTC) Received: from [195.4.92.26] (helo=16.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NHefN-0001qT-Mi for current@FreeBSD.org; Mon, 07 Dec 2009 15:34:21 +0100 Received: from p57ae2680.dip0.t-ipconnect.de ([87.174.38.128]:17508 helo=ernst.jennejohn.org) by 16.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NHefN-00061G-8j for current@FreeBSD.org; Mon, 07 Dec 2009 15:34:21 +0100 Date: Mon, 7 Dec 2009 15:34:20 +0100 From: Gary Jennejohn To: current@FreeBSD.org Message-ID: <20091207153420.26772260@ernst.jennejohn.org> In-Reply-To: <20091128182351.3e245ad6@ernst.jennejohn.org> References: <20091128111501.34a7a2a4@ernst.jennejohn.org> <20091128182351.3e245ad6@ernst.jennejohn.org> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: core dump in cvsup caused by _once()? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 14:34:22 -0000 "Sean C. Farley" wrote: > Also, cvsupd will core dump (SIGILL) when built on stable/8 amd64 > r199641 when a connection to it is made from csup. An i386-built > cvsupd will run correctly on the same system. For cvsupd, it is dying > at dladdr(), but I have not had time to debug it further. > I'm seeing this now also on 9-CURRENT AMD64 using a world installed today (but compiled yesterday). I'd decided to recompile cvsup/cvsupd with debugging in an effort to figure out why a newly installed zoneinfo/UTC causes cvsup to dump core. Some gdb output: Core was generated by `cvsupd'. Program terminated with signal 4, Illegal instruction. Reading symbols from /lib/libz.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.5 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008005c0ae0 in symlook_default () from /libexec/ld-elf.so.1 (gdb) bt #0 0x00000008005c0ae0 in symlook_default () from /libexec/ld-elf.so.1 #1 0x00000008005c132b in find_symdef () from /libexec/ld-elf.so.1 #2 0x00000008005c1403 in _rtld_bind () from /libexec/ld-elf.so.1 #3 0x00000008005be57d in _rtld_bind_start () from /libexec/ld-elf.so.1 If I run cvsupd under ktrace it does not fail. It also does not fail if I don't specify the -C flag. In both these case cvsupd basically runs in the foreground. It almost looks like the normal case, with -C and a fork of cvsupd, results in the death of the child because the parent cvsupd keeps running. Very weird. Last week it still worked. --- Gary Jennejohn