Linux strace command tutorial

strace command is a powerful tool that displays all system calls made by user space programs. Strace displays the parameters of these calls and returns the value in symbolic form. Strace receives information from the kernel and does not need to build the kernel in any special way. The following record several common options. The 1 -f -F option tells strace to trace both the fork and vfork processes 2 -o xxx.txt to a file. 3 -e execve only records system calls such as execve ————————————————— process fails to start, software The running speed suddenly slows down, the program's "SegmentFault", etc. are all headaches for every Unix system user. This article demonstrates how to use truss, strace and ltrace three common debugging tools to quickly diagnose through three practical cases. Software & quoquo; intractable diseases & rdquo;. Truss and strace are used to track the system call or signal generation of a process, while ltrace is used to track the process call library functions. Truss was an early debugger developed for System V R4. Most Unix systems, including Aix and FreeBSD, come with this tool. Strace was originally written for SunOS systems, and ltrace first appeared in GNU/DebianLinux. These two tools have now been ported to most Unix systems. Most Linux distributions come with strace and ltrace, and FreeBSD can also install them via Ports. Not only can you debug a new program from the command line, you can also bind truss, strace, or ltrace to an existing PID to debug a running program. The basic usage of the three debugging tools is basically the same. The following only introduces the three common, and is the most commonly used three command line parameters: -f: In addition to tracking the current process, it also tracks its child processes. -o file : Writes the output information to the file file instead of displaying it to the standard error output (stderr). -p pid : Bind to a running process corresponding to pid. This parameter is often used to debug background processes. Most of the debugging tasks can be done using the above three parameters. Here are a few command line examples: truss -o ls.truss ls -al: Tracks the operation of ls -al and writes the output to the file /tmp/In ls.truss. Strace -f -o vim.strace vim: Traces the operation of vim and its child processes, and writes the output information to the file vim.strace. Ltrace -p 234: Track a process that is already running with a pid of 234. The output format of the three debugging tools is also very similar, taking strace as an example: brk(0) = 0× 8062aa8 brk(0×8063000) = 0× 8063000 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0× 92f ) = 0× 40016000 Each line is a system call, the left side of the equal sign is the name of the function called by the system and its parameters, and the right side is the return value of the call. Truss, strace, and ltrace work in much the same way. They use ptrace system calls to track the progress of debugging operations. The detailed principles are beyond the scope of this article. Interested parties can refer to their source code. Two examples demonstrate how to use these three debugging tools to diagnose software's "difficulty": Case 1: Running a clint with a Segment Fault error Operating system
: FreeBSD-5.2.1-release clint is A C++ static source code analysis tool, after installing through Ports, run: # clint foo.cpp Segmentation fault (core dumped) Meet on Unix system & quoquo;Segmentation Fault> Just like popping up in MS Windows
& rdquo; illegal operation & rdquo; dialog box is just annoying. OK, we use truss to clint”put the pulse”: # truss -f -o clint.truss clint Segmentation fault (core dumped) # tail clint.truss 739: read(0×6,0×806f000,0×1000) = 4096 (0×1000) 739: fstat(6,0xbfbfe4d0) = 0 (0×0) 739: fcntl(0×6,0×3,0×0) = 4 (0×4) 739: fcntl(0× ;6,0×4,0×0) = 0 (0×0) 739: close(6) = 0 (0×0) 739: stat(”/root/.clint/plugins”,0xbfbfe680) ERR# 2 ‘No such file or directory& rsquo; SIGNAL 11 SIGNAL 11 Process stopped because of: 16 process exit, rval = 139 We use truss to track clint's system call execution and output the result to the file clint.truss, then use tail to view The last few lines. Note the last system call executed by clint (the fifth last line): stat(”/root/.clint/plugins”,0xbfbfe680) ERR#2 ‘No such file or directory’, the problem is here: clint looking Less than the directory ”/root/.clint/plugins”, which caused a segmentation error. How to solve it? Very simple: mkdir -p /root/.clint/plugins, but this time running clint will still "Segmentation Fault". Continue to use truss tracking, found that clint also needs this directory ” /root /.clint /plugins /python & rdquo;, after the establishment of this directory clint finally can run normally. Case 2: The startup speed of vim is obviously slower. Operating system: FreeBSD-5.2.1-release vim version is 6.2.154. After running vim from the command line, it takes about half a minute to enter the editing interface, and there is no error output. Carefully checked that .vimrc and all vim scripts are not misconfigured, and there is no solution to similar problems on the Internet. Is it hacking source code? No need, use truss to find the problem: # truss -f -D -o vim.truss vim The role of the -D parameter here is: add a relative timestamp before each line of output, that is, each time a system call is executed time. As long as we pay attention to which system calls take a long time, we can look at the output file vim.truss with less and quickly find the suspect: 735: 0.000021511 socket(0×2,0×1,0×0) = 4 (0×4) 735: 0.000014248 setsockopt(0×4,0×6,0×1,0xbfbfe3c8,0×4) = 0 (0×0)