Perhaps we should revert the commit that made CTF/DTRACE on by default?
At least then we could continue testing everything else? (Of course,
once we figure out and fix the problem with nbctfmerge, we would
re-enable DTRACE...)
It seems to me that we're losing a lot more functionality by not having
the automated build-and-test systems running as compared to losing
DTRACE-and-CTF-by-default.
On Tue, 9 Feb 2016, Andreas Gustafsson wrote:
The amd64 build also hangs in nbctfmerge. Here's a backtrace
and thread list:
(gdb) where
#0 0x00007f7ff689f63a in ___lwp_park60 () from /usr/lib/libc.so.12
#1 0x00007f7ff6c0b7e4 in ?? () from /usr/lib/libpthread.so.1
#2 0x00000000004048b1 in worker_thread ()
#3 0x00007f7ff6c0a9cc in ?? () from /usr/lib/libpthread.so.1
#4 0x00007f7ff6883d70 in ?? () from /usr/lib/libc.so.12
#5 0x0000000000000000 in ?? ()
(gdb) info threads
Id Target Id Frame
4 LWP 2 0x00007f7ff689f63a in ___lwp_park60 () from
/usr/lib/libc.so.12
3 LWP 3 0x00007f7ff7c0c50a in ___lwp_park60 () from
/usr/libexec/ld.elf_so
2 LWP 4 0x00007f7ff689f63a in ___lwp_park60 () from
/usr/lib/libc.so.12
* 1 LWP 1 0x00007f7ff689f63a in ___lwp_park60 () from
/usr/lib/libc.so.12
(gdb)
I'm disabling the amd64 builds, too. Let's hope at least sparc still
builds so that we don't lose our entire automated testing
infrastructure to this.
--
Andreas Gustafsson, [email protected]
!DSPAM:56ba3df154578286514747!
+------------------+--------------------------+------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+
