Bug 193109

Summary:	[dtrace] cannot compile psinfo.d: line 37: syntax error near "uid_t"
Product:	Base System	Reporter:	Enji Cooper <ngie>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed DUPLICATE
Severity:	Affects Only Me	CC:	markj, mikhail.rokhin
Priority:	---
Version:	CURRENT
Hardware:	Any
OS:	Any

Description Enji Cooper freebsd_committer

2014-08-28 23:24:14 UTC

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

Comment 1 Mark Johnston freebsd_committer

2014-08-29 18:57:43 UTC

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?

Comment 2 Mark Johnston freebsd_committer

2014-08-29 18:59:53 UTC

(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.

Comment 3 Enji Cooper freebsd_committer

2014-08-29 20:34:44 UTC

(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...

Comment 4 Mark Johnston freebsd_committer

2014-08-29 20:41:12 UTC

Can you reproduce this by running a failing test manually? Are the tests running in a chroot or jail or something?

Comment 5 mikhail.rokhin 2018-11-05 18:44:47 UTC

bug #232995

Comment 6 Mark Johnston freebsd_committer

2018-11-06 01:37:05 UTC


*** This bug has been marked as a duplicate of bug 232675 ***