From owner-freebsd-current@FreeBSD.ORG Sat May 5 21:08:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 178EA1065673; Sat, 5 May 2012 21:08:21 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 38B5C8FC18; Sat, 5 May 2012 21:08:20 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so407442wgb.31 for ; Sat, 05 May 2012 14:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5fjj8vyZ2/9mll+PHF8HDAdJkLlMyL2e+xaAAUfgdW4=; b=fC8ZhbW5/Mv/Uakx1f0AOJGXbBXiiYAB9unK8l5RTotJPhY+8u/gtfbUowyI0bOALU MHn/nNva4SQSLlp9Go4O1grVJHcC8mn0vu/hjUWJ7ZD1BSUnhMx8ITDmzkN5DIM+U+mN bSDmfAbp7a/vNMn1jh3XIaJz4OQYI2ewONnNuPsHOQCJ3Ue4w+aX5D9E5F8vl6pgL5LY BPWSAxCebewJg+mEADiZaHO7K7pVDCKb+PdPC1G2YrQfHidcSOiXMA6FZlYUwGJeCD/2 5UfY7nvtHchPWTVHs4+03GUf7+9UG9FEM4VHUITXsXWnnqY6tEKh0ipW2VwpIzb6DV7L uVCA== MIME-Version: 1.0 Received: by 10.216.133.139 with SMTP id q11mr6574812wei.44.1336252098926; Sat, 05 May 2012 14:08:18 -0700 (PDT) Received: by 10.180.97.232 with HTTP; Sat, 5 May 2012 14:08:18 -0700 (PDT) In-Reply-To: <4FA58672.1040201@FreeBSD.org> References: <4FA58672.1040201@FreeBSD.org> Date: Sat, 5 May 2012 17:08:18 -0400 Message-ID: From: "b. f." To: Steve Wills , davidxu@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ctfmerge core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 21:08:21 -0000 On 5/5/12, Steve Wills wrote: > On 05/05/12 15:43, b. f. wrote: >> Steve Wills wrote: >>> After updating from -CURRENT as of April 5 to one built today, I now get >>> a core dump running ctfmerge on libc: >>> >>> ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So...... >>> Bus error (core dumped) >>> *** [libc.so.7] Error code 138 >>> >>> Anyone else seeing this or have any idea how to avoid it? >> >> Yes, I'm also seeing such problems when attempting to build a r235052 >> amd64 kernel on r235035 amd64. (This problem did not occur when >> building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge >> succeeds for several kernel modules but fails with kgssapi.ko.debug, >> linux.ko.debug, or kernel.debug. I'm not yet sure which change has >> caused this, or how to avoid it. >> > > Thanks for the info. I took a look at the dump and see this: > > % sudo gdb /usr/bin/ctfmerge ctfmerge.core > [GDB will not be able to debug user-mode threads: Undefined symbol > "td_thr_getxmmregs"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 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 "amd64-marcel-freebsd"... > Core was generated by `ctfmerge'. > Program terminated with signal 10, Bus error. > Reading symbols from /lib/libctf.so.2...done. > Loaded symbols for /lib/libctf.so.2 > Reading symbols from /usr/lib/libdwarf.so.3...done. > Loaded symbols for /usr/lib/libdwarf.so.3 > Reading symbols from /usr/lib/libelf.so.1...done. > Loaded symbols for /usr/lib/libelf.so.1 > Reading symbols from /lib/libz.so.6...done. > Loaded symbols for /lib/libz.so.6 > Reading symbols from /lib/libthr.so.3...done. > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00000000004064b0 in fifo_len (f=0x801c29070) at > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 > 128 for (i = 0, fn = f->f_head; fn; fn = fn->fn_next, i++); > (gdb) bt > #0 0x00000000004064b0 in fifo_len (f=0x801c29070) at > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 > #1 0x000000000040622c in worker_thread (wq=0x610ee0) at > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 > #2 0x0000000801078da9 in thread_start (curthread=0x801c0f800) at > /usr/src/lib/libthr/thread/thr_create.c:284 > #3 0x0000000000000000 in ?? () > Cannot access memory at address 0x7fffff5fb000 > (gdb) > After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b.