0.4.6 (Jun 30th, 2015)

New dependencies:

• dtrace-utils-devel now always pulls in the corresponding version of dtrace-utils, rather than being satisfied with whatever version is installed. [Introduced in DTrace 0.3.0.]

• The DTrace kernel header package was renamed dtrace-modules-shared-headers in dtrace-modules 0.4.4; dtrace-utils now follows this renaming.

New options:

• dtrace -vV now reports information on the released version of dtrace, as well as the internal version-control ID of dtrace(1) and libdtrace(1). (The last two should always be the same unless the installation is faulty.)

Bugfixes:

• Processes that receive SIGTRAP in normal operation now work even when being dtraced for a ustack(), etc. Previously, the SIGTRAP would be ignored. [Introduced -- intentionally -- in DTrace 0.4.5, though this case would have misbehaved in other ways since 0.4.0.]

• DTrace no longer loses track of processes that exec() while DTrace is looking at their dynamic linker state.

• DTrace no longer leaves breakpoints lying around in fork()ed processes, but properly detaches from them and removes its breakpoints.

• DTrace no longer considers that it knows the state of the symbol table of processes it has since stopped monitoring.

• DTrace no longer crashes multithreaded processes that do dlopen() / dlclose(). [All introduced in DTrace 0.4.0.]

Library interface changes:

• Including <dtrace.h> used to fail because of the absence of a Solaris-specific header we did not ship. That header is no longer called for.

Changes to user-visible internals:

• DTrace now loads D libraries (with translators, etc) from directories with a name that depends upon the running kernel, so can support multiple kernels with the same userspace package.

Known problems:

• Multithreaded processes under u{stack,sym,addr,mod}() which do dlopen() in threads other than the first may not have accurate symbol resolution for symbols introduced by such dlopen()s.