example: root@freebsd:~ # dtrace -n 'kinst::virtqueue_poll: /cpu == 1/' dtrace: invalid probe specifier kinst::virtqueue_poll: /cpu == 1/: syntax error near end of input the same command with an empty expression: root@freebsd:~ # dtrace -n 'kinst::virtqueue_poll: /cpu == 1/{}' | head dtrace: description 'kinst::virtqueue_poll: ' matched 83 probes CPU ID FUNCTION:NAME 1 73362 virtqueue_poll:137 1 73363 virtqueue_poll:141 1 73364 virtqueue_poll:144 1 73365 virtqueue_poll:151 1 73366 virtqueue_poll:155 1 73367 virtqueue_poll:158 1 73355 virtqueue_poll:112 1 73356 virtqueue_poll:115 1 73357 virtqueue_poll:118 dtrace: failed to write to <stdout>: Broken pipe root@freebsd:~ #
(In reply to Mina Galić from comment #0) A predicate requires a body, this is not a kinst bug. FBT does the same thing: # dtrace -n 'fbt::virtqueue_poll: /cpu == 1/' dtrace: invalid probe specifier fbt::virtqueue_poll: /cpu == 1/: syntax error near end of input # dtrace -n 'fbt::virtqueue_poll: /cpu == 1/{}' dtrace: description 'kinst::virtqueue_poll: ' matched 2 probes
I was not the one to rename it ;) 0mp asked me to open a bug, and then renamed it
From what I can see this isn't a bug, but rather a request to change D's grammar to make '<probe> /<filter>/' equivalent to '<probe> /<filter>/{}'. This isn't unreasonable, but without a patch or a volunteer to work on this I'm inclined to close the report.
👍 i have bigger fish to fry, and limited time, so I'm okay with this line of action. but, yeah, basically, doing the thing that awk doesq, or giving a better hint in the error would be cool
Apparently, this patch doesn't really work and, in fact, allowing a predicate with no acts is probably impossible in D without introducing a significant amount of complexity. awk can do that just fine because awk's predicates cannot contain unescaped "/", since it searches for regexes. D on the other hand allows normal computation inside the predicate, meaning one can do division inside it: kinst::vm_fault: /(cpu / 2) == 1/ This is a problem because the D lexer considers "/" to be a division token (and not a start/end of predicate token) when the next non-whitespace character coming after it is anything other than EOF, 0, ;, { and }, so if we try and run: kinst::vm_fault: /cpu == 1/ fbt::malloc:entry The lexer will think the end of predicate is actually a division token because the succeeding non-whitespace character "f" doesn't match the character set that indicate the end of predicate.
n.b.: this is in reference to https://reviews.freebsd.org/D39167 thank you very much for your investigation!