A large percentage of the DTrace testcases fail with these errors. DTrace is properly compiled and enabled in the kernel. It's having issues in the preprocessor compiling anything related to gid_t, uid_t, and u_int in the D script. Once I comment those out, then it gets stuck on "struct proc" (says it can't find the structure). You need to use the isilon-atf-integrate-dtrace branch in http://github.com/yaneurabeya/freebsd in order to make progress here. $ uname -a FreeBSD freebsd-11-x64.localdomain 11.0-CURRENT FreeBSD 11.0-CURRENT #12 r270674+0129dfc(isilon-atf-integrate-dtrace): Tue Aug 26 16:50:36 PDT 2014 root@freebsd-11-x64.localdomain:/usr/obj/usr/src/sys/GENERIC-DEBUG amd64
This type of error is almost always the result of some sort of misconfiguration. A couple of things to check: 1. Is kern.bootfile set to the correct path for the running kernel? 2. Is there CTF data present in the kernel?
(In reply to Mark Johnston from comment #1) > This type of error is almost always the result of some sort of > misconfiguration. A couple of things to check: > > 1. Is kern.bootfile set to the correct path for the running kernel? > 2. Is there CTF data present in the kernel? The latter can be checked with something like 'ctfdump /boot/kernel/kernel'. If nothing interesting turns up, try running a dtrace command manually on the system in question, e.g. "dtrace -n 'fbt::kern_ioctl:entry'" or so. If it fails with the same error, try running it again with the DTRACE_DEBUG environment variable set to 1 and paste the output.
(In reply to Mark Johnston from comment #2) > (In reply to Mark Johnston from comment #1) > > This type of error is almost always the result of some sort of > > misconfiguration. A couple of things to check: > > > > 1. Is kern.bootfile set to the correct path for the running kernel? > > 2. Is there CTF data present in the kernel? > > The latter can be checked with something like 'ctfdump /boot/kernel/kernel'. Yup, that's ok: % [ -n "$(ctfdump $(kenv kernelname))" ] && echo "I have CTF in the kernel" I have CTF in the kernel > If nothing interesting turns up, try running a dtrace command manually on > the system in question, e.g. "dtrace -n 'fbt::kern_ioctl:entry'" or so. If > it fails with the same error, try running it again with the DTRACE_DEBUG > environment variable set to 1 and paste the output. That command works (and prints out info) $ sudo dtrace -n 'fbt::kern_ioctl:entry' dtrace: description 'fbt::kern_ioctl:entry' matched 1 probe CPU ID FUNCTION:NAME 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 1 34641 kern_ioctl:entry 0 34641 kern_ioctl:entry 1 34641 kern_ioctl:entry ^C $ I don't know how the preprocessing and resolution of C typedefs is handled with dtrace, but it seems like the issue is there and not in the actual dtrace runtime...
Can you reproduce this by running a failing test manually? Are the tests running in a chroot or jail or something?
bug #232995
*** This bug has been marked as a duplicate of bug 232675 ***