Date: Sat, 5 May 2012 17:08:18 -0400 From: "b. f." <bf1783@googlemail.com> To: Steve Wills <swills@freebsd.org>, davidxu@FreeBSD.org Cc: freebsd-current@freebsd.org Subject: Re: ctfmerge core dump Message-ID: <CAGFTUwOCGURAHUwa=xYAMj6Yf=MkQ=7cG=gGOJ0tYLqEZMkk3A@mail.gmail.com> In-Reply-To: <4FA58672.1040201@FreeBSD.org> References: <CAGFTUwOX1bM1i1a6e1c3AgpV0KCfbc7gbvkdRLq4MwdZ6QnY9A@mail.gmail.com> <4FA58672.1040201@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/5/12, Steve Wills <swills@freebsd.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGFTUwOCGURAHUwa=xYAMj6Yf=MkQ=7cG=gGOJ0tYLqEZMkk3A>