Running Linux, 5th Edition - Matthias Kalle Dalheimer [405]
= =18037= =
= =18037= = ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
= =18037= = malloc/free: in use at exit: 10 bytes in 1 blocks.
= =18037= = malloc/free: 1 allocs, 0 frees, 10 bytes allocated.
= =18037= = For a detailed leak analysis, rerun with: --leak-check=yes
= =18037= = For counts of detected errors, rerun with: -v
The figure at the start of each line indicates the process ID; if your process spawns other processes, even those will be run under Valgrind's control.
For each memory violation, Valgrind reports an error and gives us information on what happened. The actual Valgrind error messages include information on where the program is executing as well as where the memory block was allocated. You can coax even more information out of Valgrind if you wish, and, along with a debugger such as gdb, you can pinpoint problems easily.
You may ask why the reading operation in line 7, where an initialized piece of memory is read, has not led Valgrind to emit an error message. This is because Valgrind won't complain if you pass around initialized memory, but it still keeps track of it. As soon as you use the value (e.g., by passing it to an operating system function or by manipulating it), you receive the expected error message.
Valgrind also provides a garbage collector and detector you can call from within your program. In brief, the garbage detector informs you of any memory leaks: places where a function malloc'd a block of memory but forgot to free it before returning. The garbage collector routine walks through the heap and cleans up the results of these leaks. Here is an example of the output:
owl$ valgrind --leak-check=yes --show-reachable=yes nasty
...
= =18081= = ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
= =18081= = malloc/free: in use at exit: 10 bytes in 1 blocks.
= =18081= = malloc/free: 1 allocs, 0 frees, 10 bytes allocated.
= =18081= = For counts of detected errors, rerun with: -v
= =18081= = searching for pointers to 1 not-freed blocks.
= =18081= = checked 4029376 bytes.
= =18081= =
= =18081= = definitely lost: 0 bytes in 0 blocks.
= =18081= = possibly lost: 0 bytes in 0 blocks.
= =18081= = still reachable: 10 bytes in 1 blocks.
= =18081= =
= =18081= = 10 bytes in 1 blocks are still reachable in loss record 1 of 1
= =18081= = at 0x40065CFB: malloc (vg_clientmalloc.c:618)
= =18081= = by 0x8048470: main (nasty.c:5)
= =18081= = by 0x402D67EE: _ _libc_start_main (in /lib/libc.so.6)
= =18081= = by 0x8048381: _ _libc_start_main@@GLIBC_2.0 (in /home/kalle/tmp/nasty)
= =18081= =
= =18081= = LEAK SUMMARY:
= =18081= = possibly lost: 0 bytes in 0 blocks.
= =18081= = definitely lost: 0 bytes in 0 blocks.
= =18081= = still reachable: 10 bytes in 1 blocks.
= =18081= =
By the way, Valgrind is not just a very useful memory debugger; it also comes with several other so-called skins. One of these is cachegrind, a profiler that, together with its graphical frontend kcachegrind, has become the profiler of choice for many. cachegrind is slowly replacing gprof in many projects.
Interface Building Tools
A number of applications and libraries let you easily generate a user interface for your applications under the X Window System. If you do not want to bother with the complexity of the X programming interface, using one of these simple interface-building tools may be the answer for you. There are also tools for producing a text-based interface for programs that don't require X.
The classic X programming model has attempted to be as general as possible, providing only the bare minimum of interface restrictions and assumptions. This generality allows programmers to build their own interface from scratch, as the core X libraries don't make any assumptions about the interface in advance. The X Toolkit Intrinsics (Xt) toolkit provides a rudimentary set of interface widgets (such as simple buttons, scrollbars, and the like), as well as a general interface for writing your own widgets if necessary. Unfortunately this can require