Linux Debugging Tools

Document Sample
Linux Debugging Tools Powered By Docstoc
					Shell Script Debugging – Day 1

As all of you know bugs­free softwares (of real complexity) are not just rare, but they do not exist. And so, finding out bugs 
from the software and fixing them or in other words "DEBUGGING" is a continuous process.

Wiki says
"Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a 
piece of electronic hardware thus making it behave as expected".

In this week, we will make you aware of various debugging tools and how they can be used in order to solve various types 
of problems e.g., programing errors, scripting error, kernel is misbehaving, system is misbehaving and etc. 

We got an overview and basics about shell scripts during last Techpedia week. So,lets start with how to debug shell scripts.

Shell Script Debugging

[1] Debugging on part(s) of the script

Using the "set" Bash built­in you can run in normal mode those portions of the script of which you are sure they are 
without fault, and display debugging information only for troublesome zones. 

    set ­x            # activate debugging from here. It will display commands and their arguments as they are executed.
    set +x            # stop debugging from here
The same option can be set as "set ­o xtrace"

    Similarly,
    set ­v            #Display shell input lines as they are read.
    set +v            #Disable
The same option can be set as "set ­o verbose"

Below example shows usage of both the options. Script is just reading three arguments and we want to make sure that script 
is getting exactly what we are passing from command line.
[root@viral temp_shell_cmds]# cat example.sh
set ­v #debugging of script is start from here
    if [ $# ­ne 3 ]
    then
        echo "$0: number1 number2 number3 are not given" >&2
        exit 1
    fi
set ­x
    n1=$1
    n2=$2
    n3=$3
set +x
set +v #debugging of script is stop from here
[root@viral temp_shell_cmds]#
[root@viral temp_shell_cmds]#
[root@viral temp_shell_cmds]#
[root@viral temp_shell_cmds]# sh example.sh 5 10 15
    if [ $# ­ne 3 ]
    then
        echo "$0: number1 number2 number3 are not given" >&2
        exit 1
    fi
set ­x
    n1=$1
+ n1=5
    n2=$2
+ n2=10
    n3=$3
+ n3=15
set +x
[root@viral temp_shell_cmds]#                           
 

    set ­e              # It will cause bash to exit with an error on very first erroneous command.
    set ­o pipefail     # It will cause bash to exit with an error on very first erroneous command in a pipeline as well.


[root@viral temp_shell_cmds]# set ­o pipefail
[root@viral temp_shell_cmds]# date ­s | cut ­f 2 ­d " "
date: option requires an argument ­­ s
Try `date ­­help' for more information.
[root@viral temp_shell_cmds]# echo $?
1
[root@viral temp_shell_cmds]# set +o pipefail
[root@viral temp_shell_cmds]# date ­s | cut ­f 2 ­d " "
date: option requires an argument ­­ s
Try `date ­­help' for more information.
[root@viral temp_shell_cmds]# echo $?
0




As there is no option like "­s" for date command, it is failing. You can see the final command output when "pipefail" is set 
or not set.
Note: echo $? shows the output of last command.

[2] Multi­line commenting


During the debugging process, we may also find a need to do multi­line commenting. 

Single line code:: One line of shell code can be "commented out" using the "#" character.
However, there isnt any direct syntax for multi­line commenting but below is a trick.

(a) One way to comment out multiple lines is this:
    : '
    ,,,,,,
    '
Example:
[root@viral temp_shell_cmds]# cat example.sh
: `echo "This is first line in comment"
echo "This is second line in comment"`
echo "I am out of comment section"

[root@viral temp_shell_cmds]# sh example.sh
I am out of comment section
[root@viral temp_shell_cmds]#


(b) Another way to comment out multiple lines of code is the "here document"
way:
    : << ­­END­COMMENT­­
    your comment here
    ­­END­COMMENT­­

With this way, there is no restriction with single quotes.
[root@viral temp_shell_cmds]# cat example.sh
: << ­­END­COMMENT­­
`echo "This is first line in comment"
echo "This is second line in comment"`
­­END­COMMENT­­
echo "I am out of comment section"
[root@viral temp_shell_cmds]# sh example.sh
I am out of comment section
[root@viral temp_shell_cmds]#




[3] Debugging through Signals

There is a well­known trick in debugging is sending signal to program and knowing its status. Lets see how that can be 
done.

The trap command allows you to execute a command when a signal is received by your script. It works like this:
Syntax :: trap arg signals
"signals" is a list of signals to intercept and "arg" is a command to execute when one of the signals is received. 
[root@viral temp_shell_cmds]# cat example.sh
VAR1=$1
VAR2=$2
my_func ()
{
        echo Var1 is $VAR1
}
trap "my_func" SIGHUP SIGINT SIGTERM
while ((1))
do
        VAR1=`expr $VAR1 + 1`
        sleep 1
done

[root@viral temp_shell_cmds]#
[root@viral temp_shell_cmds]#
[root@viral temp_shell_cmds]#               
[root@viral temp_shell_cmds]# sh example.sh 1
Var1 is 2
Var1 is 6
Var1 is 9

[3]+  Stopped                 sh example.sh
[root@viral temp_shell_cmds]#


Here we have added a trap command that will print a value of the variable, in question, for us whenever we want to know as 
and when we are passing signal.

Note:
There is one signal that you cannot trap: SIGKILL or signal 9.
System Monitoring Tools – Day 2

Continuing with our tips on debugging tools. Today, we will have Tips on System Monitoring Tools.

1. ps 

It gives information about Process States. Below is an example of how "ps" output looks like and what each and every field 
means

[root@viral ~]# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2419  0.0  0.3   8512  1636 ?        Ss   17:34   0:00 sendmail: accepting connections
root      2439  0.0  0.0   1868   360 ?        Ss   17:34   0:00 gpm ­m /dev/input/mice ­t exps2
root      2484  0.0  0.2   5216  1096 ?        Ss   17:34   0:00 crond
xfs       2537  0.0  0.4   3968  2204 ?        Ss   17:34   0:00 xfs ­droppriv ­daemon
root      2558  0.0  0.0   2204   424 ?        Ss   17:34   0:00 /usr/sbin/atd
root      2595  0.0  2.1  24424 11252 ?        S    17:34   0:00 /usr/bin/python /usr/sbin/yum­updatesd 
Where,
PID­ Process ID,    VSZ ­ virtual memory size of the process in KiB,    RSS ­ resident set size, the non­swapped physical 
memory that a task has used
STAT ­ multi­character process state,    WCHAN ­ address of the kernel function where the process is sleeping

PROCESS STATE CODES
Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the 
state of a
process.
D    Uninterruptible sleep (usually IO)                     For BSD formats and when the stat keyword is used, additional 
R    Running or runnable (on run queue)                     characters may be displayed:
S    Interruptible sleep (waiting for an event to           <    high­priority (not nice to other users)
complete)                                                   N    low­priority (nice to other users)
T    Stopped, either by a job control signal or because it  L    has pages locked into memory (for real­time and custom IO)
is being traced.                                            s    is a session leader
W    paging (not valid since the 2.6.xx kernel)             l    is multi­threaded (using CLONE_THREAD, like NPTL 
X    dead (should never be seen)                            pthreads do)
Z    Defunct ("zombie") process, terminated but not         +    is in the foreground process group
reaped by its parent.


Lets see some examples where "ps" comes as handy,
When you want to see the starting order of processes
On systems that do not randomize the process numbers, sorting running services by the PID may indicate when or where an 
early process was started.
    ps awx | sort ­n
When you want to list processes in a hierarchy
    ps ­e ­o pid,args ­­forest 
When you want to list processes by % cpu usage
    ps ­e ­o pcpu,cpu,nice,state,cputime,args ­­sort pcpu | sed '/^ 0.0 /d' 
When you want to list all threads for a particular process
    ps ­C firefox­bin ­L ­o pid,tid,pcpu,state 
When you want to list info for particular process IDs
    ps ­p 1,2 
When you have a feel that your system has become quite slow. And when the CPU is loaded and, for example, processes are 
blocked because of I/O, say a read from the disc and disc is slow OR some process went to sleep when it shouldn't have. 
Look at process STAT. Additionally you can see that process is waiting on which function.
Look at the Yello marked field in below output.
[root@viral ~]# ps axl
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0     0  3078  3066  25   0   4436  1088 wait   S    ?          0:00 /bin/sh /usr/lib/firefox­1.5.0.9/run­mozilla.sh 
/usr/lib/firefox­1.5.0.9/firefox­bin
4     0  3083  3078  15   0 200600 57636 stext  Sl   ?          1:18 /usr/lib/firefox­1.5.0.9/firefox­bin


2. top 

It gives  system summary information as well as a list of tasks currently being managed by the Linux kernel. 

The top command displays the most CPU­ or memory­intensive processes in real time. It provides an interactive interface 
for manipulation of processes and allows sorting by different criteria, such as CPU usage or memory usage. Below is an 
example output.

[root@viral ~]# top
top ­ 17:48:20 up 14 min,  0 users,  load average: 0.25, 0.10, 0.07              |
Tasks: 117 total,   1 running, 116 sleeping,   0 stopped,   0 zombie             |
Cpu(s):  1.2%us,  0.2%sy,  0.0%ni, 98.5%id,  0.0%wa,  0.2%hi,  0.0%si,  0.0%st   | Summary Area
Mem:    513756k total,   502748k used,    11008k free,    58464k buffers         |
Swap:  2048248k total,        0k used,  2048248k free,   235740k cached          |

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND             |
 2844 root      15   0  219m  15m 5200 S    2  3.1   0:15.98 Xorg                |
 3041 root      15   0 35148  13m 9720 S    1  2.7   0:02.34 konsole             |
 3028 root      15   0 37840  16m  12m S    0  3.3   0:03.05 kicker              | Task Area
 3309 root      15   0  2160 1020  788 R    0  0.2   0:00.05 top                 |
    1 root      15   0  2032  648  552 S    0  0.1   0:00.52 init                |
Where,
PR ­ Priority of the task,   NI ­ nice value of the task i.e., used in determining task's dispatchability
VIRT ­ Amount of virtual memory used,   RES ­ Resident size,     SHR ­ Shared mem size,     S ­ State of a task.

Lets see some examples where "top" comes as handy,
When you want to see real time process list in order of CPU usage, or mem usage, or virt mem usage, sequence of 
commands will be as follows
    top <press return>
    O <i.e., Capital O> This will bring up a list and you can select any field through which you want to sort your processes
    n <This will sort all processes w.r.t. memory usage>
You can change delay when output is refreshed. 
    top ­d 1 <delay is specified as 1 Sec, so the output will refresh every second>
Additionally, you can view task related to specific user, kill a process, also renice the process. 
    
3. lsof 

It gives list of open files. Open files in the system include disk files, pipes, network sockets and devices opened by all 
processes

COMMAND    PID      USER   FD      TYPE     DEVICE     SIZE       NODE NAME
init         1      root  cwd       DIR        3,2     4096          2 /
init         1      root  rtd       DIR        3,2     4096          2 /
init         1      root  txt       REG        3,2    38620    3677635 /sbin/init
init         1      root  mem       REG        3,2   121684      67341 /lib/ld­2.5.so
init         1      root  mem       REG        3,2  1576952      67342 /lib/libc­2.5.so
telnet    3139      root  mem       REG        3,2    76392      67356 /lib/libresolv­2.5.so
telnet    3139      root  mem       REG        3,2   559532    1948342 /usr/lib/libkrb5.so.3.2
telnet    3139      root    0u      CHR      136,4                   6 /dev/pts/4
bash      3178      root    2u      CHR      136,5                   7 /dev/pts/5
bash      3178      root  255u      CHR      136,5                   7 /dev/pts/5
lsof      3320      root  cwd       DIR        3,2    12288    2375713 /root 
Where,
PID ­  Process ID,   FD ­ File descriptor number,    TYPE ­ Type of node associated with file i.e., directory, sock, block file, 
char file and etc.
DEVICE ­ Device numbers     SIZE ­ size of the file,     NODE ­ node or inode number of a local file

Lets see some examples where "lsof" comes as handy,
When a disk cannot be unmounted because (unspecified) files are in use. lsof helps to identify the process that is using the 
files.
    lsof /mnt/C (It will give a list of files opened that have specified path.)
When we want to list paths that process ID has opened.
    lsof ­p <Process ID> (If I want to know my vpnclient is using which all files, I will follow a command sequence of ps/top 
and then lsof)
When we want to have user specific info as well. 
    lsof­uviral 
When we want to list processes that have specified path open
    lsof <path> (e.g., lsof /opt)

Please refer 
man ps, man top and man lsof for more details.
Memory Debugger Tool – Day 3


[amee@localhost Debug] cat test_efence.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main()
{
    char *arr;    int i;
    arr = (char *)malloc(sizeof(char)*5);
    strcpy(arr,"amee is my name");
    return 0;
}


Above four­liner code is definitely having a problem. Quite visible. We have malloced memory of 5 bytes and then we are 
writing past malloc boundry.
But, what do you think, running it on any intelligent Linux box would give any error ? I bet for most of the time it will not 
panic. 

But, consider it as a snippet from some large code. Imagine that we have malloced the memory, copied some content to it 
and then we are freeing the memory at some later stage.
As soon as you will try to free the memory, OS will send SIGSEGV and prog will come out with SegFault.
Now think, you have introduced a problem while copying the content to memory (i.e., in strcpy), and the problem appeared 
while freeing (i.e., in free() ) the memory.

Any debuggers like gdb and etc will not help you to locate the exact location of errors. That is exactly where Memory 
Debugger Tools will help. Yeah, you have guessed it right, today's Tip is on "Electric Fence ­ A Memory Debugger"

Introduction:

Electric Fence helps you detect two common programming bugs:
    software that overruns the boundaries of a malloc()memory allocation,
    software that touches a memory allocation that has been released by free().
    Unlike other malloc() debuggers, Electric Fence will detect read accesses as well as writes, and it will pinpoint the exact 
instruction that causes an error.

Electric Fence uses the virtual memory hardware of your computer to place an inaccessible memory page immediately after 
(or before, at the user's option) each memory allocation. 

Usage:

You can use the ­lefence argument to the linker, otherwise you'll have to put the path­name for libefence.a in the linker's 
command line.
export LD_PRELOAD=libefence.so.0.0 will cause Electric Fence to be loaded to run all dynamic executables. 
Make sure you are not linking with ­lmalloc, ­lmallocdebug, or with other malloc­debugger or malloc­enhancer libraries.
Run your program using a ­lefence. Create a core file. If your program has one of the errors detected by Electric Fence, it 
will get a segmentation fault (SIGSEGV) at the offending instruction. Use the debugger(i.e GDB) to locate the erroneous 
statement, and repair it.

You can set environment EF_PROTECT_BELOW or EF_PROTECT_FREE or EF_ALLOW_MALLOC_0 or EF_FILL in 
order to debug various problems.

Example:


[amee@localhost Debug]$ gcc ­g ­Wall ­lefence test_efence.c
[amee@localhost Debug]$ ./a.out

  Electric Fence 2.2.0 Copyright (C) 1987­1999 Bruce Perens <bruce@perens.com>
Segmentation fault (core dumped)

[amee@localhost Debug]$ gdb a.out core.5450
GNU gdb Red Hat Linux (6.5­16.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386­redhat­linux­gnu"...Using host libthread_db 
library "/lib/libthread_db.so.1".



warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libefence.so.0...done.
Loaded symbols for /usr/lib/libefence.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld­linux.so.2...done.
Loaded symbols for /lib/ld­linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x08048484 in main () at test_efence.c:11
11              strcpy(arr,"amee is my name");
(gdb)


Electric Fence can be downloaded here, http://linux.softpedia.com/get/Programming/Debuggers/Electric­Fence­3305.shtml
Kernel Crash Debug – Day 4

First of all, bunch of thanks to Ajay for voluntarily preparing today's tip on behalf of Sumit.
Today we will talk about kernel crash debugging technique using crash utility.

Introduction:
Most frequent issue in debugging kernel programs is lack of information; lack of information in terms of stack trace, kernel 
logs and crash screen­shots.
Crash utility provides solution for this. It provides gdb like interface for debugging.

Prerequisites:
1. vmlinux object file. This is kernel image with debugging information. By default, we get compressed kernel image with 
no debug information.
For getting, vmlinux object file, you need to install "kernel­debuginfo" rpm.
2. If you want to debug any module, make sure it is compiled with gcc flag '­g'.

Installation:
We receive crash utility as rpm. rpm name is of format: crash­$version.$arch.rpm
    Here, $version shows version number and $arch shows system architecture.

For getting crash dump:
For getting crash dump, we need to add "crashkernel" option to grub command line.
i.e. we can have:
    ro root=LABEL=/1 rhgb quiet crashkernel=128M@16M
instead of,
    ro root=LABEL=/1 rhgb quiet

Here, parameter "crashkernel=128M@16M" reserves 128MB of physical memory starting at 16MB. This reserved memory 
is used to preload and run the capture kernel (i.e. to capture crash dump).
This command line option ensures that, whenever crash occurs, it stores crash dump at "/var/crash" and they are stored 
according to date and time.

There are other options to get crash dump like diskdump, netdump, etc.

Running crash Utility:
1. Debugging last kernel panic:
 # crash <patht to vmlinux> /var/crash/crash_dump_name
2. Watching current running kernel:
 # crash
This will prompt to crash shell. Just as example, following are commands:
 crash> help
 crash> bt                    ­­­> for backtrace
 crash> log                  ­­­> for dumping current system buffer

For more information on this, you can visit at:
http://www.redhatmagazine.com/2007/08/15/a­quick­overview­of­linux­kernel­crash­dump­analysis/
http://people.redhat.com/anderson/crash_whitepaper/
Setting up KGDB – Day 5

Continuing with Tips on various debugging tools, we will introduce KGDB to you today. 
It is fascinating to think that you have control over running Linux Kernel. You can stop, can single­step, can resume and 
even can put break­points on running Kernel. In fact, you can debug the kernel as easily as you debug any application.

Today we will learn how to setup kgdb environment such that we can, at least, do very basic kernel debugging.

Keep in mind that, the steps mentioned here are with reference to 2.6.26 Kernel. The main reason is KGDB code is merged 
into Linux tree from 2.6.26­RC5 kernel.
(As a side note, for kernel < 2.6.26­RC5, you have to get kgdb patch from http://kgdb.linsyssoft.com/kernel.htm and apply 
them to kernel)

Hardware Requirements
       
Two x86 machines are required for using KGDB. One of the machines runs a kernel to be debugged called "TEST 
MACHINE". The other machine runs gdb "DEVELOPMENT MACHINE".
A serial line is required between the development and the test machine. And so obviously, machines need one serial port 
each. Basically, you will be sending "Debugging Commands" from "DEVELOPMENT MACHINE" to "TEST MACHINE".

Preparing Kernel to be Debugged

1. Download the source of kernel (for e.g., 2.6.26.2)from kernel.org 

2. Recompile the Kernel on "DEVELOPMENT MACHINE".

­> Go to Kernel Hacking 
        ­> Enable two options 1. Enable SysRq Key, and 2. Kernel Debugging KGDB. 
Give "Y" to both of them.


3. Build kernel and modules 
make ­j 12 && make modules && make modules_install


4. Transfer the vmlinux and system.map and initrd.img files on "TEST MACHINE".

5. Now, edit the GRUB entry for that kernel on "TEST MACHINE". Add kernel options/kernel parameters like kgddbwait 
and kgdboc=ttyS0,115200
For e.g., kernel /vmlinux ro root=LABEL=/ rhgb quiet crashkernel=128M@16M 
kgddbwait kgdboc=ttyS0,115200
kgdbwait ­­ > This will make Kernel to wait on boot time and will expect someone to connect to it and give further 
commands
kgdboc ­­> This is a KGDB I/O driver and we are supplying two arguments. ttyS0 will tell that communication will happen 
on Serial Port 0 and 115200 is the baudrate.

6. Now boot the Kernel with those kernel parameters.

7. On dev machine, start GDB session.
[dev@root]gdb vmlinux
The argument vmlinux file is the file that is created with Debug symbols. 
It will be of much larger size and more than likely to be in the directory where you gave "make" command..

8. Assuming that on "DEVELOPMENT MACHINE" you have set serial interface baudrate as 115200. Connect to the 
"TEST MACHINE" with target command.
(gdb)target remote /dev/ttyS0


9. This will stop your Kernel booting on "TEST MACHINE" and will give control to your "DEVELOPMENT MACHINE". 
Now, you can do Single­stepping or put breakpoints and etc.

10. Once your Kernel is running on "TEST MACHINE" and you want control over your running kernel from 
"DEVELOPMENT MACHINE",
    You have to send MANUALLY on TEST machine SysRq command. So, on "TEST MACHINE" press SysRq + g (i.e., 
press "ALT" key then Press "PrintScreen" Key and then Press "g" key)

There are several possible problems that you may face
1. Your Kerenel is booted and SysRq+g is not working.
[r00t@root] echo 1 > /proc/sys/kernel/sysrq
This will enable sending SysRq commands.

2. You may find some time that while stopping execution through SysRq key on "TEST MACHINE", it stops but then it is 
not able to communicate over serial cable with "DEVELOPMENT MACHINE". The reason can be, your KGDB I/O driver 
is not passed arguments properly and you may need to reconfigure the driver by following way,
[root@test]echo "ttyS0,115200" > /sys/modules/<module name>/parameters
System Trace Tools – Day 6
 
Today we will learn about the utility which can trace System Calls and Signals. 
That utility is "strace".
 
Introduction:

strace can be seen as a light weight debugger. It allows a programmer / user to quickly find out how a program is interacting 
with the OS. It does this by monitoring system calls and signals. strace is invoked with the program to be traced as the 
argument, or with the "­p" option with a PID number to trace a process that is already running. The "­s" option to set the 
string size is highly recommended if you need to examine the input and output of a program.
 
Usage:
The use of strace is quite simple:
# strace  <name of the program>


Real Time Problem:

Here we will explain "strace" to solve a particular problem. Suppose we have installed all the multimedia codecs 
including the libdvdcss which allows to play DVDs in Linux. But after installing all the necessary codecs, when we tried 
playing a DVD movie, through totem (it's a open source utility helps to play movie file) gave an error saying that it was 
unable to play the movie. Since we know that necessary libraries are already installed, it should be able to play.

Next, lets trace what is happening and take a look.
# strace ­o strace.totem totem
====================================================
Output:
# Output of strace on totem
open("/etc/ld.so.cache", O_RDONLY)      = 26
fstat64(26, {st_mode=S_IFREG|0644, st_size=58317, ...}) = 0
old_mmap(NULL, 58317, PROT_READ, MAP_PRIVATE, 26, 0) = 0xb645e000
close(26)
open("/lib/tls/i686/cmov/libdvdcss.so.2", O_RDONLY) = ­1 ENOENT (No such 
file or directory)
stat64("/lib/tls/i686/cmov", {st_mode=S_IFDIR|0755, st_size=1560, ...}) = 0
stat64("/lib/i486­linux­gnu", 0xbfab4770) = ­1 ENOENT (No such file or directory)
munmap(0xb645e000, 58317)               = 0
open("/usr/lib/xine/plugins/1.1.1/xineplug_inp_mms.so", O_RDONLY) = 26
read(26, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\27"..., 512) = 512
fstat64(26, {st_mode=S_IFREG|0644, st_size=40412, ...}) = 0


Here, you can see Yellow marked line. The player was not able to open, necessary CODEC file that we had already 
installed. Now doing "ls" to that location, showed that there was nt any file there and instead it was at some other location. 
Just copying the libdvdcss.so.2 file at the location "/lib/tls/i686/cmov/" solved the problem.
 
Few Important Options:
 
­c
 
Count time, calls, and errors for each system call and report a summary on program exit. On Linux, this attempts to show 
system time (CPU time spent running in the kernel) independent of wall clock time. If ­c is used with ­f or ­F (below), only 
aggregate totals for all traced processes are kept.
 
Example:
# strace ­c cat /dev/null
====================================================
Output:
execve("/bin/cat", ["cat", "/dev/null"], [/* 29 vars */]) = 0
% time     seconds  usecs/call     calls  errors   syscall
­­­­­­ ­­­­­­­­­­­ ­­­­­­­­­­­ ­­­­­­­­­ ­­­­­­­­­ ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
 31.50    0.000063          13         5         1     open
 16.50    0.000033           7         5                old_mmap
 15.50    0.000031          31         1                mmap2
  7.50    0.000015           3         5                 fstat64
  6.50    0.000013           3         5                 brk
  6.00    0.000012           6         2                 read
  6.00    0.000012           2         5                 close
  5.00    0.000010          10         1                munmap
  3.50    0.000007           7         1                 uname
  2.00    0.000004           4         1                 set_thread_area
­­­­­­ ­­­­­­­­­­­ ­­­­­­­­­­­ ­­­­­­­­­ ­­­­­­­­­ ­­­­­­­­­­­­­­­­­­­­­­­­­­­­
100.00    0.000200                    31         1 total
====================================================
The list shows 1 error in the summary due to failure in open system call above.

­d
Show some debugging output of strace itself on the standard error.

­i
Print the instruction pointer at the time of the system call.

­f
Trace child processes as they are created by currently traced processes as a result of the fork system call.

­q
Suppress messages about attaching, detaching etc. This happens automatically when output is redirected to a file and the 
command is run directly instead of attaching.

­a column
Align return values in a specific column (default column 40).

For more information regarding rest of the options, please refer to man pages of strace.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:10
posted:3/27/2012
language:English
pages:14
Description: List of great tips for debugging in Linux by using tools and commands.