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