Re: bin/58630: dtrace is "hit or miss", but mostly "miss"

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

I did some more testing, it's pretty easy to do, just stick that
segment from the PR in probes.d, and do

        /usr/sbin/dtrace -s ./probes.d -h -o probes.h

and watch it either succeed or fail.  There's apparently support
for dtrace on a relatively small set of NetBSD targets (powerpc
and sparc64 are not supported, for example).

Anonymizing (and extending) my report slightly, I get

+-- dtrace probes.d -h OK?  x = OK, f = Fail
! 
v hostname      arch    NetBSD kernel   Userland        Build ID

x trxxx         amd64   9.2             9.2             202105121714Z
x kaxxxxxxx     i386    9.2             9.1             202010182324Z
x flxxx         i386    9.3             9.3             202208041543Z
f bixx          amd64   9.3             9.3             202208041543Z
x tixxxxxxxxxs  amd64   9.2             9.2             202105121714Z
x joxxxxxxxx    i386    10.0_RC1        10.0_RC1        202312141900Z
f raxxxxxx      amd64   10.0_RC4        10.0_RC4        202402061416Z
x smxxxxx       amd64   10.0_RC3        10.0_RC3        202401161016Z
f rox-xxd       amd64   10.0            10.0_RC6        n/a (Mar 26)
x hexxx         amd64   10.0            10.0            202403281259Z
f rox-xxl       amd64   10.0            10.0            202403281259Z
x oxx-xes       amd64   10.0            10.0            n/a (May 29)
x txx-xes       amd64   10.0            10.0            n/a (Jun 3)
x huxxx         amd64   10.0            10.0            202403281259Z
x nx            amd64   10.0            10.0_STABLE     202407270640Z
x bxx-xes       amd64   10.0            10.0_STABLE     202407270640Z
f oxxxxn        amd64   10.0            10.0_STABLE     202407270640Z
f xs            amd64   10.0            10.0_STABLE     202407270640Z
f sxxxx.xxx     amd64   10.99.11        10.0            n/a (May 25)

Userland is "DISTRIBVER" from /etc/release.
Build ID is "Build ID" or "Build date" from /etc/release.
These two indicate the vintage of user-land in use on the host,
and those which are locally built don't have a Build ID.

So, the bug appears to be present on both 9.x, 10.x and -current
systems.

I'm really confused as to what factor is influencing whether this
bug surfaces or not, and would encourage others to provide new
entries in this table.  And of course if someone has further
hints for debugging, that would be appreciated as well.

And, yes, I know that I'm running newer user-land code than
kernel on the 10.0 / 10.0_STABLE systems, which is usually a
no-no, especially along the trunk, but "it's fine", and is what I
did to get a post-1-jul-2024 sshd installed on those systems.

Regards,

- Håvard