1.219.  systemtap

On-file flight recording is now supported. This allows stap to run in the background and record huge trace log information on the disk, rather than just to memory. (BZ#438737)

Kernel tracepoints are now supported for probing predefined kernel events without any debuginfo information. Tracepoints incur less overhead than kprobes, and context parameters are available with full type information. For a list of available, supported tracepoints, run the command stap -L 'kernel.trace("*")'. (BZ#475456 and BZ#498040)

A SystemTap initscript is now included with this release, and is provided by the package systemtap-initscript. This initscript allows users to run SystemTap scripts as system services (in flight recorder mode) and control those scripts individually. For more information, refer to /usr/share/doc/systemtap-initscript-<version>/README.initscript. (BZ#474906 and BZ#481705)

This update resolves a ref-count problem that prevented uprobes from properly disposing the uprobe_process struct on exec while there are outstanding uretprobe instances. In addition, a bug that caused utrace to incorrectly report events-in-progress to a recently-created engine is now fixed as well. These fixes address several uretprobe bugs that could cause the system to hang in previous releases. (BZ#478711)

SystemTap log rotation is now supported. With this, a running SystemTap script can switch to a different log file during on-file flight recording without stopping. Users can specify a time or log file size that triggers a log rotation, helping ensure that a SystemTap script never stops recording information. (BZ#481704)

stapprep.sh is a script documented in the SystemTap Beginner's Guide, used to determine and download (when able) the kernel information packages needed to run SystemTap. This script is now included by default in the systemtap package as the command stap-prep. (BZ#485498)

When stap passed a kill signal to its children, it was possible for that signal to be sent to all other processes in the same process group. This could include processes other than its children. This was because SystemTap used system() to manipulate process groups. With this update, SystemTap now uses stap_system() instead of system(); this allows stap to save the process ID of all its children, ensuring that stap only sends signals to its children. (BZ#494462)

Probes that used insn probe points failed. While the upstream version of SystemTap fully supports the use of insn probe points, the kernel and utrace versions used by Red Hat Enterprise Linux 5 did not define the required macros arch_has_single_step() and arch_has_block_step(). With this release, SystemTap defines these macros during compile time whenever insn probe points are used. (BZ#498018)

The systemtap-testsuite package contained test cases (systemtap.base/bz10078.stp, buildko/two.stp, and buildok/thirty.stp) that were incorrectly configured as "executable". Any test runs involving these cases failed unexpectedly. This release fixes the permissions for all test cases provided by the systemtap-testsuite package. (BZ#499657)

The context.stp tapset now contains a definition for the task_pt_regs() macro, which is required to compile some types of SystemTap scripts on the PowerPC platform. (BZ#499688)

Compiling any program that used static dynamic trace markers for the STAP_PROBE or DTRACE_PROBE macros on the PowerPC platform resulted in an error. This was caused by an incorrect if/else statement in the sdt.h headr file, did not define PowePC as required; as such, the sdt.h header file supplied an incorrect macro definition for STAP_NOP. With this update, sdt.h now provides the correct macro definition for STAP_NOP on the PowerPC platform. (BZ#501795)

A bug in the implementation of kernel return probe trampolines made it possible for some stack tracebacks to go undetected. Whenever this occurred, the stack unwinder would not be executed, resulting in a garbled stack. With this release, the code for detecting the kernel return probe trampoline is now fixed, ensuring that all stack tracebacks are dealt with accordingly. In addition, this release also uses the kernel DWARF unwinder automatically in the event of stack tracebacks. (BZ#503225)

A bug in runtime/task_finder.c made it possible for some processes to hold a semaphore while performing a memory map callback. Whenever this occurred, some tasks would become deadlocked if they were probed by user-space probes. This update fixes the bug, ensuring that memory map callbacks are safe and do not cause deadlocks. (BZ#504007)