R Programming for Bioinformatics

Chapter 9

Debugging and Profiling

9.1 Introduction

In this chapter we provide some guidance on tools and strategies that should

make debugging your code easier and faster. Basically, you must first try to

identify the source of the error. While it is generally easy to find where the

program actually failed, that is not usually the place where the programming

error occurred. Some bugs are reproducible; that is, they occur every time a

sequence of commands is executed on all platforms, and others can be more

elusive; they arise intermittently and perhaps only under some operating sys-

tems. One of the first things that you should do when faced with a likely bug

is to try and ensure its reproducibility. If it is not easily reproduced, then

your first steps should be to find situations where it is, as only then is there

much hope of finding the problem.

One of the best debugging strategies is to write code so that bugs are

less likely to arise in the first place. You should prefer the use of simple

short functions, each performing a particular task. Such functions are easy to

understand and errors are often obvious. Long, convoluted functions tend to

b oth give rise to more bugs and to be more difficult to debug.

This chapter is divided into several sections. First we discuss the browser

function, which is the main tool used in debugging code in R. R functions such

as debug, trace and recover make use of browser as a basic tool. The debugging

to ols are all intended primarily for interactive use and most require some form

of user input. We then discuss debugging in R, beginning by recommending

that static code analysis using functions from the codetools package be used,

and then covering some of the basic tools that are available in R. Then we cover

debugging procedures that can be applied to detect problems with underlying

compiled code. We conclude by discussing tools and methods for profiling

memory and the execution of R functions.

273

274 R Programming for Bioinformatics

9.2 The browser function

The browser function is the building block for many R debugging techniques.

A call to browser halts evaluation and starts a special interactive session where

the user can inspect the current state of the computations and step through

the code one command at a time. The browser can be called from inside any

function, and there are ways to invoke the browser when an error or other

exception is raised.

Once in the browser, users can execute any R command; they can view

the local environment by using ls; and they can set new variables, or change

the values assigned to variables simply by using the standard methods for

assigning values to variables. The browser also understands a small set of

commands specific to it. A summary of the available browser commands

and other useful R commands are given in Table 9.1 and Table 9.2. Of these,

p erhaps the most important to remember for new users is Q, which causes R to

quit the debugger and to return control to the command line. Any user input

is first parsed to see if it is consistent with a special debugger instruction and,

if so, the debugger instruction will be performed. Most of these commands

consist of a single letter and are described below. Any local variable with the

same name as one of these commands cannot be viewed by simply typing its

name, as is standard practice in R, but rather will need to be wrapped in a

call to print.

ls() list the variables defined inside the function

x print the value of variable x

print(x) print the value of variable x – useful when x is one of n, l, Q or cont

where print the call stack

Q stop the current execution and return to the top-level R interpreter

prompt

Table 9.1: Browser commands with non-mo dal functionalities.

When the browser is active, the prompt changes to Browse[i]> for some

p ositive integer i. The browser can be invoked while a browser session is

active, in which case the integer is incremented. Any subsequent calls to

browser are nested and control returns to the previous level once a session has