|
|
$ memtool your_prog its_args
memtool analyzes and reports detailed information about the following misuses of allocated memory:
In this context, ``blocks'' are the individual objects that comprise the allocation ``arena'' -- the objects whose addresses are returned by malloc(S) or new(C++std).
memtool can only detect dynamic memory misuses as provided by the checking features documented in malloc(S). For example, it cannot detect general pointer misuses, the overrunning of local or global arrays, or distinguish between intended and unintended use of a block.
Each diagnostic includes one to three stack traces:
Also note that you cannot run truss(C) and memtool on the same process, because the /proc file system does not permit truss and debug (which is used by memtool) to be run on the same process. Therefore, a command line like the following will fail with an error:
memtool truss ...
$ cat bad.c
#include <stdlib.h>
static void *f(void *p) {
free(p);
return malloc(0);
}
int main(void) {
char *p = malloc(13);
p[13] = 'x';
f(p);
p = realloc(p, 7);
return 0;
}
Building it and running it, we see nothing wrong:
$ cc -g -o bad bad.c $ ./bad $ echo $? 0But, if run with memtool:
$ memtool ./badwe get nearly a hundred lines of diagnostics, including the following. Note that bad.c was compiled with the -g option to generate debugging information, so the memtool output is more detailed than it would otherwise be.
A block's spare bytes have been modified. This usually occurs due to writing beyond the block's regular bytes, either because an insufficient number of bytes were requested when the block was allocated or simply due to a programming logic error.as well as a complaint about the misuse of realloc():History for block at address 0x80496f8: *Stack trace when detected: [0] free(ptr=0x80496f8) [1] f(p=0x80496f8) [bad.c@3] in ./bad [2] main(0x1,0x8047a34,0x8047a3c) [bad.c@9] in ./bad [3] _start() [0x804856c] in ./bad
*Stack trace when block at 0x80496f8 was allocated: [0] malloc(sz=13) [1] main() [bad.c@7] in ./bad [2] _start(presumed:0x1,0x8047a34,0x8047a3c) [0x8048571] in ./bad
Annotated snapshot surrounding the live allocation at address 0x80496f8 when the byte at 0x8049705 was found to have been modified. This allocation holds 13 bytes followed by 7 extra (or spare) bytes, and, in this case, a spare byte was found to have been modified.
0x80496f0: 0x08047a34 0x00000019 0xcacacaca 0xcacacaca 4z.............. : ******** -------- -------- ****-------- 0x8049700: 0xcacacaca 0xcaca78ca 0xcacacaca 0x0000001d .....x.......... : -------- ++++^^-- ++++++++ -----^++++++
A recently free()d block was passed as the first argument to realloc(). Only null pointers or live block addresses are permitted to be passed to realloc(), although, in this implementation, were dynamic memory checking not enabled, this block's contents would have been preserved between its being freed and this call to realloc(), but this is a nonportable feature of this implementation which should not be relied on.There were also complaints about two leaked blocks. If the -z option were used, memtool would also generate a warning about theHistory for block at address 0x80496f8: *Stack trace when detected: [0] realloc(ptr=0x80496f8,sz=7) [1] main(0x1,0x8047a34,0x8047a3c) [bad.c@10] in ./bad [2] _start() [0x804856c] in ./bad
*Stack trace when block at 0x80496f8 was released: [0] free(ptr=0x80496f8) [1] f(p=0x80496f8) [bad.c@3] in ./bad [2] main() [bad.c@9] in ./bad [3] _start(presumed:0x1,0x8047a34,0x8047a3c) [0x8048571] in ./bad
*Stack trace when block at 0x80496f8 was allocated: [0] malloc(sz=13) [1] main() [bad.c@7] in ./bad [2] _start(presumed:0x1,0x8047a34,0x8047a3c) [0x8048571] in ./bad
malloc(0) on line 4.
Because bad.c was compiled with the -g option
to generate debugging information,
the memtool output includes the source file and line number
in the stack trace lines
as well as the parameter names.
Had the code been compiled without -g,
each function would show three hexadecimal arguments.
memtool can be run on a stripped program,
but the output will not show even the function names.