Vladimir Prus


vladimirprus.com

Thursday, April 06, 2006

Printf debugging 2006

One of the oldest methods of debugging is "printf debugging" -- putting various print statements in the code and then staring at the output. That's useful not only if you can't use a debugger. If the program does not crash, but produces wrong results after long computation, it's hard to figure where exactly the problem lies. In that case, printing intermediate data can be a very efficient method.

The only problem is that after adding print statements the program must be recompiled, and after debugging print statements must be removed. But it's possible to make gdb into printing machine using so called "breakpoint commands". Each breakpoint can have a list of commands that will be executed when breakpoint is hit. The commands can include printing and "continue". Here's a simplified example of gdb script I've used recently:

break main.cpp:1353
commands
   print ('lvk::nm_model::NM'*)this
   printf "Entering 'run', proc %d\n", $->processor_number
   continue
end
run

After putting this to a file "script", gdb can be run as:

gdb -batch -x script name_of_program > log
producing logs of variable values as certain points of the program.

Starting with version 3.3.0, similar functionality is available in KDevelop. Just click on the "Tracing" column in breakpoints window, select variables to print and click OK.

More screenshots here and here. This is a beginning, future KDevelop version will allow to specify custom commands for breakpoints.

6 comments:

Anonymous said...

Wow, never know about this useful trick.

Anonymous said...

Nice, but why do you use pixelated (non anti-aliased) fonts? It makes the writing look like it's in the stone age :)

Vladimir Prus said...

Heh, I can't control which fonts are antialised on your machine ;-)

Anonymous said...

Nice, but why do you use pixelated (non anti-aliased) fonts? It makes the writing look like it's in the stone age :)
I thought all developers preferred to avoid headache inducing blurry fonts when doing serious coding.

superstoned said...

> I thought all developers
> preferred to avoid headache
> inducing blurry fonts when doing
> serious coding.

depends on the way you anti-alias your fonts... there are ways to keep em clear and actually make em more readable.

Anonymous said...

Anonymous said...

> Nice, but why do you use
>pixelated (non anti-aliased) fonts?
>It makes the writing look like it's
>in the stone age :)

I always wonder why people look at things totally out of the topic of blog post while commenting. Its really hard for developers to blog(most of them aren't professional bloggers) keeping all these extra stuff in mind :) Thank god, atleast you weren't rude :)

Anyway this is really nice useful trick. Thanks for this tip :)
--
gopala