On 2012/5/6 5:08, b. f. wrote:
On 5/5/12, Steve Wills<swi...@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"]
Hmm, is the thread debugging broken on amd64 now ? td_thr_getxmmregs
resides
in libthread_db and /usr/src/gnu/usr.bin/gdb/libgdb is complaining about
the missing
symbol.
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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
