Project News: DTrace

[ Project Home  |  News  |  Downloads  |  Docs  |  Mailing Lists  |  Source Control  |  Issues ]


2016.01.22: DTrace userspace 0.4.6, kernel modules 0.4.5, libdtrace-ctf 0.4.3


All RPMs are available on the Unbreakable Linux Network.
Packaging and build changes:
 - Renamed the dtrace-modules-headers package to dtrace-modules-shared-headers
   to work around problems in Yum where a symbol has had both versioned and
   unversioned provides over time.
 - dtrace-utils-devel now always pulls in the corresponding version of
   dtrace-utils, rather than being satisfied with whatever version is
   installed.  libdtrace-ctf-devel and libdtrace-ctf are adjusted similarly.
New features:
 - It is now possible to use USDT probes in 32-bit applications on 64-bit
Changes to user-visible internals:
 - The DTrace module code has been restructured to facilitate supporting
   architectures other than x86_64.
 - 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.
 - It was possible to cause a system crash by passing an invalid pointer
   to d_path().  Due to its implementation, it is not possible to depend
   on safe memory accesses to avoid this.  Instead, the pointer passed as
   argument must be validated prior to calling d_path() in the kernel.
 - Fixed a (minor) memory leak problem with the help tracing facility in
   DTrace.  Upon loading the dtrace.ko module, a buffer (by default 64K)
   was being allocated, and it was never released.
 - Stack backtraces are more accurate as a result of various fixes to
   adjust the number of frames to skip for specific probes.
 - Datatypes have been adjusted to be more carefully specified after a
   detailed audit in preparation for supporting architectures other than
 - The stack depth was being determined by requesting a backtrace to be
   written into a temporary buffer that was being allocated (vmalloc),
   which posed significant problems when probes were executing in a
   context that does not support memory allocations.  The buffer is now
   obtained from the scratch area of memory that DTrace provides for
   probe processing.
dtrace-utils 0.4.6 library interface changes:
 - A pair of new libdtrace-ctf functions, ctf_snapshot() and ctf_rollback(),
   provide type-and-variable discarding functionality like that ctf_discard()
   did, but without the expense of calling ctf_update() to get a point to
   discard to.
 - #including <dtrace.h&rt; used to fail because of the absence of a
   Solaris-specific header we did not ship.  That header is no longer called
New dtrace-utils 0.4.6 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.)
dtrace-utils 0.4.6 bugfixes:
 - Processes that receive SIGTRAP in normal operation now work even when being
   dtraced for a ustack(), etc.  Previously, the SIGTRAP would be ignored.
 - 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() /
Known bugs:
 - 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.