amd64/185290: Dtrace does not work on -stable/10

[Mark Johnston]

The following reply was made to PR amd64/185290; it has been noted by GNATS.

From: Mark Johnston <markj at freebsd.org>
To: Robert David <robert.david.public at gmail.com>, bug-followup at FreeBSD.org
Cc:  
Subject: Re: amd64/185290: Dtrace does not work on -stable/10
Date: Sat, 4 Jan 2014 22:34:55 -0500

 On Mon, Dec 30, 2013 at 08:50:01PM +0000, Robert David wrote:
 > The following reply was made to PR amd64/185290; it has been noted by GNATS.
 > 
 > From: Robert David <robert.david.public at gmail.com>
 > To: Mark Johnston <markj at freebsd.org>
 > Cc: bug-followup at FreeBSD.org
 > Subject: Re: amd64/185290: Dtrace does not work on -stable/10
 > Date: Mon, 30 Dec 2013 21:43:06 +0100
 > 
 >  Hi,
 >  
 >  I got the system installed on my notebook and now does not have any
 >  jail set up. 
 >  
 >  Tried to move io.d out:
 >  
 >  root at notebook ~src (git)-[53624fa...] #
 >  mv /usr/lib/dtrace/io.d /usr/lib/dtrace/io.d.bu
 >  
 >  root at notebook ~src (git)-[53624fa...] # dtrace -n 'syscall:::entry
 >  { @num[execname] = count(); }' dtrace: invalid probe specifier
 >  syscall:::entry { @num[execname] = count(); }:
 >  "/usr/lib/dtrace/psinfo.d", line 90: failed to resolve type
 >  kernel`struct thread * for identifier curthread: Module is no longer
 >  loaded 1 
 >  root at notebook ~src (git)-[53624fa...] #
 >  
 >  Serching through internet I found this:
 >  http://lists.freebsd.org/pipermail/freebsd-dtrace/2013-October/000110.html
 >  
 >  Maybe something not backported from CURRENT.
 
 I'm testing 10.0-RC4 in a bhyve instance, and DTrace seems to be working
 properly. I will upgrade to stable/10 and test some more, but pretty much
 nothing has changed DTrace-wise between releng/10 and stable/10 so far.
 Moreover, the problems you're seeing tend to be the result of corrupted
 or absent CTF data, rather than bugs in the code.
 
 So here are a few more questions that'll help us pinpoint what's going
 on:
 - What happens when you run "ctfdump /boot/kernel/kernel"? Could you
   send the output? If it's correct, it should contain many thousands of
   lines.
 - Did you build the GENERIC kernel that you reported as having the
   issue? Do you have anything in make.conf or src.conf?
 - You mentioned that you have all of the probes (dtrace -l); do they
   have type info? For example, the command below gives the types for the
   arguments to read(2). Are they present when you run the same command?
 
 # dtrace -lv -n syscall:freebsd:read:entry
    ID   PROVIDER            MODULE                          FUNCTION NAME
 38182    syscall           freebsd                              read entry
 
 	Probe Description Attributes
 		Identifier Names: Private
 		Data Semantics:   Private
 		Dependency Class: Unknown
 
 	Argument Attributes
 		Identifier Names: Private
 		Data Semantics:   Private
 		Dependency Class: ISA
 
 	Argument Types
 		args[0]: int
 		args[1]: void *
 		args[2]: size_t
 
 Thanks!
 -Mark