Linux系统下检测程序异常有效工具_检查编程错误的软件资源-CSDN文库

linux

systemtap

4星 · 超过85%的资源需积分: 9 103 浏览量 2012-12-09 15:59:20 上传评论收藏 147KB PDF 举报

资源推荐

资源详情

资源评论

Systemtap tutorial

Frank Ch. Eigler <fche@redhat.com>

June 29, 2012

Contents

1 Introduction 2

2 Tracing 2

2.1 Where to probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 What to print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Analysis 6

3.1 Basic constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Target variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.4 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.6 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.7 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Tapsets 11

4.1 Automatic selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2 Probe point aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Embedded C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4 Naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Further information 16

A Glossary 16

B Errors 16

B.1 Parse erro rs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

B.2 Type errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

B.3 Symbol errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

B.4 Probing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

B.5 Runtime errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

C Acknowledgments 18

1 Introduction

Systemtap is a tool that allows developers and administrators to write and reuse simple scripts to deeply

examine th e activities of a live Linux system. Data may be extracted, ﬁltered, and summarized quickly and

safely, to enable diagnoses of complex performance or functional problems.

NOTE: This tutorial does not describe every feature available in systemtap. Please see the individual stap

manual pages for the most up-to-date info rmation. These may be available installed on your system, or at

http://sourceware.org/systemtap/man/.

The essential idea behind a systemtap script is to name events, and to give them handlers. Whenever a

speciﬁed eve nt occurs, the Linux kernel runs th e handler as if it were a quick subroutine, then resumes.

There are several kind of events, such as entering or exiting a function, a timer expiring, or the entire

systemtap session starting or stopping. A handler is a series of script language statements that specify the

work to b e done whenever the event occurs. This work normally includes extracting dat a from the event

context, sto ring them into internal variables, or printing results.

Systemtap wo rks by translating the script to C, running the system C compiler to create a kernel module

from that. When the module is loaded, it activates all the probed events by hooking into the ke rnel. Then,

as events occur on any processor, the compiled handlers run. Eventually, the session stops, the hooks are

disconnected, and the module removed. This entire process is driven from a single command-line program,

stap.

# cat hello-world.stp

probe begin

{

print ("hello world\n")

exit ()

}

# stap hello-world.stp

hello world

Figure 1: A systemt ap smoke test.

This paper assumes that you have installed systemtap and its prerequisite kernel development tools and

debugging data, so that you can run the scripts such as the simple one in Figure 1. Log on as root, or even

better, login as a user that is a member of stapdev group or as a user authorized to sudo, before running

systemtap.

2 Tracing

The simplest kind of pr obe is simply to trace an event. This is the effect of inserting strategically located

print statements into a pr ogram. This is often the ﬁrst step of problem solving: explore by seeing a history

of what has happened.

# cat strace-open.stp

probe syscall.open

{

printf ("%s(%d) open (%s)\n", execname(), pid(), argstr)

}

probe timer.ms(4000) # after 4 seconds

{

exit ()

}

# stap strace-open.stp

vmware-guestd(2206) open ("/etc/redhat-release", O_RDONLY)

hald(2360) open ("/dev/hdc", O_RDONLY|O_EXCL|O_NONBLOCK)

df(3433) open ("/etc/ld.so.cache", O_RDONLY)

df(3433) open ("/lib/tls/libc.so.6", O_RDONLY)

df(3433) open ("/etc/mtab", O_RDONLY)

hald(2360) open ("/dev/hdc", O_RDONLY|O_EXCL|O_NONBLOCK)

Figure 2: A taste of systemtap: a system-wide strace, just for the open system call.

This style of instrumentation is the simplest. It just asks systemtap to print something at each event. To

express this in the script language, you need to say where to probe and what to print ther e.

2.1 Where to probe

Systemtap supports a number of built-in eve nt s. The librar y of scripts that comes with systemtap, each called

a “tapset”, may deﬁne additional ones d eﬁned in terms of the built-in family. See the stapprobes man page

for details on these and many other probe point families. All these events are named using a uniﬁed

syntax with dot-separated parameterized identiﬁers:

begin The startup of the systemtap session.

end The end of the systemtap session.

kernel.function("sys_open") The entry to the function named sys_open in the kernel.

syscall.close.return The return from the close system call.

module("ext3").statement(0xdeadbeef) The addressed instruction in the ext3 ﬁlesystem driver.

timer.ms(200) A timer that ﬁres every 200 milliseconds.

timer.profile A timer that ﬁres periodically on every CPU.

perf.hw.cache_misses A p articular number of CPU cache misses have occurred.

procfs("status").read A process trying to read a synthetic ﬁle.

process("a.out").statement("*@main.c:200") Line 200 of th e a.out program.

Let’s say that you would like to trace all function ent ries and exits in a source ﬁle, say net/socket.c in t he

kernel. The kernel.function probe point lets you e xpress that easily, since systemtap examines the kernel’s

debugging information to relate object code to source code. It works like a debugger: if you can name

or place it, you can probe it. Use kernel.function("*@net/socket.c").call for the function entries

and kernel.function("*@net/socket.c").return for matching exits. Note th e use of wildcards in the

function name part, and the subsequent @FILENAME part. You can also put wildcards into the ﬁle name, and

Without the .call qualiﬁer, inlined fun ction instances are al so probed, but they have no corresponding .return.

even add a colon (:) and a line number, if you want to restrict t he search that precisely. Since systemtap will

put a separate p robe in every place that matches a probe point, a few wildcards can expand to hundreds or

thousands of probes, so be car eful what you ask for.

Once you identify the probe p oints, the skeleton of the systemtap script appears. The probe keywor d intro-

duces a probe point, or a comma-separated list of them. The following { and } b races enclose the handler

for all listed probe points.

probe kernel.function("*@net/socket.c") { }

probe kernel.function("*@net/socket.c").return { }

You can run this script as is, though with e m pty handlers ther e will be no out put. Put the t wo lines into a

new ﬁle. Run stap -v FILE. Terminate it any time with ^C. (The -v op tion tells systemtap to p rint more

verbose messages during its processing. Try the -h op tion to see more o ptions.)

2.2 What to print

Since you ar e interested in each function that was entered and exited, a line should be printed for each,

containing the function name. In order to make that list easy to read, systemtap should indent the lines so

that functions called by other traced functions are nested deeper. To tell each single process apart f rom any

others that may be running concurrently, systemtap should also print the process I D in the line.

Systemtap provides a variety of such cont extual data, ready for for m atting. They usually app ear as function

calls within the handler, like you already saw in Figure 1. See the function::* man pages for those

functions and more deﬁned in the t apset library, but here’s a sampling:

tid() The id of the current thread.

pid() The process (task group) id of the current thread.

uid() The id of the current user.

execname() The name of the current process.

cpu() The current cpu number.

gettimeofday_s() Number of seconds since epoch.

get_cycles() Snapshot of h ardware cycle counter.

pp() A string describing the probe point b eing currently handled.

probefunc() If known, the name of the function in which this probe was placed.

$$vars If available, a pretty-printed listing of all local variables in scope.

print_backtrace() If possible, print a kernel backtr ace .

print_ubacktrace() If possible, print a user-space backtrace.

The values returned may be strings or numbers. The print() built-in function accepts either as its sole

argument. Or, you can use the C-style printf() built-in, whose formatting argument may include %s for a

string, %d for a number. printf and other f unctions take comma-separated arguments. Don’t fo rget a "\n"

at the end. Th ere exist more printing / formatting functions too.

A particularly handy function in the tapset library is thread_indent. Given an indentation delta parameter, it

stores internally an indentation counter for each thread (tid()), and r eturns a string with some generic trace

data plus an appropriate number of indentation spaces. That generic data includes a timestamp (number

of microseconds since the initial indentation for the thread), a process name and the thread id itself. It

therefor e gives an idea not only about what functions were called, but who called them, and how long they

took. Figure 3 shows the ﬁnished script. It lacks a call to the exit() function, so you need to interrupt it

with ^C when you want the tracing to stop.

剩余17页未读，继续阅读

评论收藏

内容反馈

javelin2007

2017-10-12

这是一个使用工具的介绍。不是工具
疯狂的拉面

2013-08-20

明明是个ppt啊

qk064

粉丝: 0
资源: 1

Linux系统下检测程序异常有效工具

heartbeat linux 心跳检测

RED HAT LINUX 6大全

基于KRSI（eBPF+LSM）的Linux安全审计、控制和行为分析工具

通用刷盘工具无广告版

服务器运维管理手册.doc

dagda：一种工具，用于对docker images容器中的已知漏洞，特洛伊木马，病毒，恶意软件和其他恶意威胁进行静态分析，并监视docker守护程序和运行docker容器以检测异常活动

exein:基于Linux固件的Exein核心

操作系统(内存管理)

典型相关分析matlab实现代码-Alert:基于KNN算法，处理influxdb的API调用数据进行异常检测

rkhunter-1.4.2.tar.gz

免费开源的SQL注入工具SQLmap.zip

Unison是OSX，Unix和Windows的文件同步工具

IIS6.0 IIS，互联网信息服务

pro_android_cpp_with_the_ndk.pdf

构建最高可用Oracle数据库系统 Oracle 11gR2 RAC管理、维护与性能优化

exein-openwrt-public:Exein的安全框架具有Openwrt 18.06.5

QBDI:基于LLVM的动态二进制检测框架

JAVA上百实例源码以及开源项目源代码

linux aarch64架构libreoffice安装包

（牛客网C++课程）Linux 高并发Web服务器项目实战（带定时检测代码）

Linux项目设计_媒体播放器(6818).rar

谷歌浏览器驱动 Chromedriver（125.0.6422.60版本）文件

openssh-server离线安装包

jdk-8u371-linux-x64.tar.gz

VisualGDB 5.6 R9//支持VS2008-VS2022

linux下nginx离线安装包及相关依赖包（附教程）

centos 7.6版本 ISO镜像下载

最新资源