Get started with strace and debug faster

Bug bumper

© Stuart Monk, Fotolia

© Stuart Monk, Fotolia

Article from Issue 103/2009
Author(s):

Get started with strace by examining a pair of "Hello World" programs. Next month, in the second part of this two-part series, I'll take a deeper look at strace output.

Strace is a useful little program – installed by default on most Linux systems – that allows you to take a look at the system calls used by an application. Don't be misled by the name: strace doesn't provide a stack trace – it just reports on system calls.

If you are having problems with a homegrown application – or with any application that offers you access to the source code – you can use strace to help determine where a program is crashing or what problems it is having. Even if you are not tracing a problem, strace is useful because it can help you find out more about what your system is doing, which can sometimes help with performance tuning and resource management.

In this article, I'll help you get started with strace by examining a pair of "Hello World" programs – one in Perl (a scripting language) and one in C (a compiled language). Next month, I'll cover some more advanced situations and take a deeper look into the strace output.

The Command

The basic strace command is:

strace program_name

However, this outputs everything straight to standard error (i.e., to the screen), and, as I'll show, there can be quite a lot of output. Thus, it's usually best to use the -o option to specify an output file:

strace -o outputfile.txt program_name

Some editors, such as vim, are able to do syntax highlighting of strace output. The syntax highlighting feature will display different parts of the file – and different parts of each line – in different colors. When you are trying to make sense of strace output, which can look a little confusing, this technique is particularly useful, and I strongly recommend you use an editor that offers syntax highlighting.

Strace on Perl

Consider the "Hello World" Perl script shown in Listing 1. In case you're not familiar with Perl, the first line tells the shell what program to use to run this script and, in this case, also sets the -w flag, which turns warnings on. The use strict statement turns the strict module on; use strict, which lets you see what output you get when loading a module, and -w are not really necessary in this script, but they are good habits. Finally, the last line prints the string "Hello, Perl!" with a newline at the end.

Listing 1

helloworld.pl

01 #!/usr/bin/perl -w
02 use strict;
03 print "Hello, Perl!\n";

After you've saved this script, change to the directory that it's in, make the script executable with chmod u+x helloworld.pl, and then, before you start looking at it with strace, run ./helloworld.pl to make sure the script contains no typos. Once you know the script is working, run strace on it with:

strace -o strace_perl.out ./helloworld.pl

Next, open up the strace output file in an editor (Figure 1). The output might look a little intimidating, but don't worry about the details yet. Instead, look at the basic structure of each line. Strace outputs each system call as a single line, with the call name at the start of the line, its arguments in brackets, and the return value after the equals sign at the end of the line. Listing 2 shows the first lines of strace output.

Figure 1: Strace output in vim.

Listing 2

Example strace Output Lines

01 execve("./helloworld.pl", ["./helloworld.pl"], [/* 20 vars */]) = 0
02 uname({sys="Linux", node="the.earth.li", ...}) = 0

In your Perl strace, you'll first see a line stating what script you're executing. The next line (Listing 2) is a call to uname, showing the details of your system. What uname actually returns is a pointer to the data structure; strace fills this information in for you. (By default, it only prints some of the information, but you can also request more detailed information.)

Whenever strace encounters a pointer to a data structure, it gives you the information pointed at rather than the pointer itself.

Access Calls

Next you'll see some access calls, which attempt to access information in specific files (see Listing 3). The access call shows what file the program is trying to access (e.g., /etc/ld.so.preload) and whether the attempt was successful. The -1 means unsuccessful, and the notice of failure is often accompanied with an error code (E  *: or in this case, ENOENT). Then the error code is translated into plain English; ENOENT means "no such file or directory."

If the file does exist, access checks to see whether the program is allowed to access it (e.g., if the permissions are correctly set).

Listing 3

Access Calls

01 access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
02 open("/etc/ld.so.cache", O_RDONLY)      = 3
03 fstat(3, {st_mode=S_IFREG|0644, st_size=43270, ...}) = 0
04 mmap(NULL, 43270, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b8740901000
05 close(3)                                = 0

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Practical strace

    After "Hello World," you really need to look at system calls in more detail. In this second of two articles, we'll look at debugging in the real world.

  • Debugging for Admins

    Whether you’re the sys admin of a home network or of a company-wide network of dozens or even hundreds of machines, some basic principles of debugging will come in handy.

  • Perl: Ptrace

    Linux lets users watch the kernel at work with a little help from Ptrace, a tool that both debuggers and malicious process kidnappers use. A CPAN module introduces this technology to Perl and, if this is not enough, C extensions add functionality.

  • Tracing Tools

    Programs rarely reveal what they are doing in the background, but a few clever tools, of interest to both programmers and administrators, monitor this activity and log system functions.

  • How to Write a Rootkit

    Today’s rootkits infiltrate a target system at kernel level, thus escaping unwanted attention from administrators. Read on for a practical look at how a kernel rootkit really works.

comments powered by Disqus

Direct Download

Read full article as PDF:

Strace.pdf (2.16 MB)

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia