e7bd1c5ec2ec3819fcff6f3d0717003f9efe50ba
[sliver-openvswitch.git] / utilities / ovs-parse-leaks.8
1 .TH ovs\-parse\-leaks 8 "August 2010" "Open vSwitch" "Open vSwitch Manual"
2 .
3 .SH NAME
4 ovs\-parse\-leaks \- parses OVS leak checker log files
5 .
6 .SH SYNOPSIS
7 \fBovs\-parse\-leaks\fR [\fIbinary\fR] \fB< \fIlog\fR
8 .
9 .SH DESCRIPTION
10 Many Open vSwitch daemons accept a \fB\-\-check\-leaks\fR option that
11 writes information about memory allocation and deallocation to a log
12 file.  \fBovs\-parse\-leaks\fR parses log files produced by this
13 option and prints a summary of the results.  The most interesting part
14 of the output is a list of memory blocks that were allocated but not
15 freed, which Open vSwitch developers can use to find and fix memory
16 leaks.
17 .PP
18 The log file must be supplied on standard input.  The binary that
19 produced the output should be supplied as the sole non-option
20 argument.  For best results, the binary should have debug symbols.
21 .
22 .SH OPTIONS
23 .TP
24 \fB\-\-help\fR
25 Prints a usage message and exits.
26 .SH BUGS
27 The output can be hard to interpret, especially for a daemon that does
28 not exit in normal operation.  Using \fBovs\-appctl\fR(8) to invoke
29 the \fBexit\fR command that some Open vSwitch daemons support
30 sometimes helps with this.
31 .PP
32 \fBovs\-parse\-leaks\fR usually incorrectly reports one or more ``bad
33 frees of not-allocated address'' errors at the beginning of output.
34 These reflect frees of data that were allocated before the leak
35 checker was turned on during program initialization.