From owner-freebsd-current@FreeBSD.ORG Sat Nov 28 17:23:53 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 5DC9F1065676; Sat, 28 Nov 2009 17:23:53 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 991F08FC0C; Sat, 28 Nov 2009 17:23:52 +0000 (UTC) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NER1T-0003Hj-VW; Sat, 28 Nov 2009 18:23:51 +0100 Received: from td828.t.pppool.de ([89.55.216.40]:10383 helo=ernst.jennejohn.org) by 8.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NER1T-0007WG-LT; Sat, 28 Nov 2009 18:23:51 +0100 Date: Sat, 28 Nov 2009 18:23:51 +0100 From: Gary Jennejohn To: "Sean C. Farley" Message-ID: <20091128182351.3e245ad6@ernst.jennejohn.org> In-Reply-To: References: <20091128111501.34a7a2a4@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: current@FreeBSD.org 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: Sat, 28 Nov 2009 17:23:53 -0000 On Sat, 28 Nov 2009 09:16:01 -0600 (CST) "Sean C. Farley" wrote: > On Sat, 28 Nov 2009, Gary Jennejohn wrote: > > > Since I installed a new world and kernel on November 26 I'm seeing > > core dumps with cvsup, even though I reinstalled cvsup yesterday. > > > > Here the output from a gdb session without any debugging symbols: > > > > Core was generated by `cvsup'. > > 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 0x00000008009edcf7 in gmtime_r () from /lib/libc.so.7 > > (gdb) bt > > #0 0x00000008009edcf7 in gmtime_r () from /lib/libc.so.7 > > #1 0x00000008009ed79e in gmtime_r () from /lib/libc.so.7 > > #2 0x00000008009ee420 in gmtime_r () from /lib/libc.so.7 > > #3 0x00000008009ee638 in gmtime_r () from /lib/libc.so.7 > > #4 0x00000008009f1988 in _once () from /lib/libc.so.7 > > #5 0x00000008009ed41f in timeoff () from /lib/libc.so.7 > > #6 0x00000008009eeca7 in gmtime () from /lib/libc.so.7 > > #7 0x00000000004a643a in calloc () > > #8 0x000000000043aec7 in ?? () > > #9 0x0000000000448eaa in ?? () > > #10 0x0000000000409ece in ?? () > > #11 0x00000000004191a4 in ?? () > > #12 0x0000000000417cbe in ?? () > > #13 0x000000000041529f in ?? () > > #14 0x0000000000414d7a in ?? () > > #15 0x000000000049f980 in calloc () > > #16 0x000000000048fa3d in fnmatch () > > #17 0x00007fffffffd3e8 in ?? () > > #18 0x00007fffffffe950 in ?? () > > #19 0x00007fffffffea40 in ?? () > > #20 0x00007fffffffea28 in ?? () > > #21 0x0000000000000000 in ?? () > > #22 0x0000000000000000 in ?? () > > #23 0x00001fa00000037f in ?? () > > #24 0x0000000000000000 in ?? () > > #25 0x00000000006476c0 in ?? () > > #26 0x00000000006476c0 in ?? () > > #27 0x0000000000494d89 in fnmatch () > > Previous frame inner to this frame (corrupt stack?) > > > > Seems to me that _once() was a very recent addition. Can't say for > > certain whether this is the culprit, but it looks suspicious to me. > > 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. > Interestingly enough, locally connecting with csup to cvsupd works just fine on 9-current from November 26. In fact, cvsup works Ok to update the CVS tree. It core dumps when it connects to cvsupd locally and tries to update the ports/src trees. --- Gary Jennejohn