Re: ctfmerge core dump
On Thursday, May 24, 2012 4:10:59 pm Sergey Dyatko wrote: 2012/5/7 Steve Wills swi...@freebsd.org On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: 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. Maybe or maybe I have done something wrong on my system. FWIW, I do all my builds with debugging enabled. BTW, just to confirm, I was able to work around the original issue once I updated past r235068. I had to disable DTrace build and build and install a new libthr, then was able to re-enable DTrace and everything was fine. Thanks, Steve hm.. looks like problem is still here. I'm trying update my r234992 to r235887 http://pastebin.com/stm7b8hQ I believe this was fixed by 235563 in HEAD. -- John Baldwin ___ 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
Re: ctfmerge core dump
2012/5/7 Steve Wills swi...@freebsd.org On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: 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. Maybe or maybe I have done something wrong on my system. FWIW, I do all my builds with debugging enabled. BTW, just to confirm, I was able to work around the original issue once I updated past r235068. I had to disable DTrace build and build and install a new libthr, then was able to re-enable DTrace and everything was fine. Thanks, Steve hm.. looks like problem is still here. I'm trying update my r234992 to r235887 http://pastebin.com/stm7b8hQ ___ 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
Re: ctfmerge core dump
On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: 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. Maybe or maybe I have done something wrong on my system. FWIW, I do all my builds with debugging enabled. BTW, just to confirm, I was able to work around the original issue once I updated past r235068. I had to disable DTrace build and build and install a new libthr, then was able to re-enable DTrace and everything was fine. Thanks, Steve ___ 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
Re: ctfmerge core dump
On Sat, May 5, 2012 at 8:26 PM, Outback Dingo outbackdi...@gmail.com wrote: On Sat, May 5, 2012 at 7:54 PM, David Xu listlog2...@gmail.com wrote: On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@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 0x004064b0 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 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. I have fixed it in r235068. hopefully itll fix kernel compilations also halting with signal 10 well seems to be okay now i did successfully get a kernel compiled ___ 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 ___ 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
Re: ctfmerge core dump
On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@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 0x004064b0 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 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (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
ctfmerge core dump
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? Let me know if you need more details on my config. Thanks, Steve ___ 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
Re: ctfmerge core dump
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. 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
Re: ctfmerge core dump
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 0x004064b0 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 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) Not sure what to make of that. Steve ___ 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
Re: ctfmerge core dump
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] 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 0x004064b0 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 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (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
Re: ctfmerge core dump
On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@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 0x004064b0 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 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. I have fixed it in r235068. ___ 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
Re: ctfmerge core dump
On Sat, May 5, 2012 at 7:54 PM, David Xu listlog2...@gmail.com wrote: On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@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 0x004064b0 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 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. I have fixed it in r235068. hopefully itll fix kernel compilations also halting with signal 10 ___ 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 ___ 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
