Valgrind快速入门指南：3.12版

需积分: 10 115 浏览量更新于2024-07-20 收藏 964KB PDF 举报

Valgrind 是一个强大的内存调试和性能分析工具，主要用于检测C/C++程序中的内存错误和性能瓶颈。这个手册是 Valgrind 的官方文档，针对的是 Release 3.12.0 版本，发布于 2016 年 10 月 20 日。版权属于 Valgrind 的作者，根据 GNU Free Documentation License（版本 1.2 或更高）进行授权，允许用户复制、分发和修改文档，但需遵守特定条款。文档主要分为六个逻辑上独立的部分： 1. **Valgrind快速入门指南**：这是快速上手 Valgrind 的起点，适合初学者了解如何安装、配置和使用这个工具进行基本的内存检查和性能监控。它会指导读者如何启动 Valgrind，以及常见的命令行选项和应用场景。 2. **Valgrind用户手册**：这是详尽的文档，涵盖了 Valgrind 功能的深入细节，包括各种工具（如 Memcheck、Callgrind 和 Helgrind）的使用方法、配置选项、报告解读以及高级用法。它是理解和精通 Valgrind 的核心资源。 3. **Valgrind FAQ**：包含了常见问题解答，可以帮助用户解决在使用过程中遇到的问题，提供实践经验分享。 4. **Valgrind技术文档**：这部分可能包含更专业或技术性的内容，例如工具背后的原理、内部实现、调试技术等，适合对 Valgrind 深度感兴趣的开发者和研究人员。 5. **Valgrind发行文档**：这部分可能涉及Valgrind的安装、更新、打包和打包后的部署指南，对于开发者构建和分发 Valgrind 有实用价值。 6. **GNU许可证**：文档中包含 GNU Free Documentation License 的副本，确保用户在使用文档时遵循开源软件的许可协议。要开始使用 Valgrind，建议首先阅读快速入门指南，了解基本概念和操作流程。然后，对于特定的需求，可以查阅用户手册来获取更深入的技术支持。遇到问题时，可以参考 FAQ 获取答案。对于对 Valgrind 的工作原理感兴趣的人，技术文档将提供深入见解。

2. Using and understanding the

Valgrind core

This chapter describes the Valgrind core services, command-line options and behaviours. That means it is relevant

regardless of what particular tool you are using. The information should be sufﬁcient for you to make effective

day-to-day use of Valgrind. Advanced topics related to the Valgrind core are described in Valgrind’s core: advanced

topics.

A point of terminology: most references to "Valgrind" in this chapter refer to the Valgrind core services.

2.1. What Valgrind does with your program

Valgrind is designed to be as non-intrusive as possible. It works directly with existing executables. You don’t need to

recompile, relink, or otherwise modify the program to be checked.

You invoke Valgrind like this:

valgrind [valgrind-options] your-prog [your-prog-options]

The most important option is --tool which dictates which Valgrind tool to run. For example, if want to run the

command ls -l using the memory-checking tool Memcheck, issue this command:

valgrind --tool=memcheck ls -l

However, Memcheck is the default, so if you want to use it you can omit the --tool option.

Regardless of which tool is in use, Valgrind takes control of your program before it starts. Debugging information is

read from the executable and associated libraries, so that error messages and other outputs can be phrased in terms of

source code locations, when appropriate.

Your program is then run on a synthetic CPU provided by the Valgrind core. As new code is executed for the ﬁrst

time, the core hands the code to the selected tool. The tool adds its own instrumentation code to this and hands the

result back to the core, which coordinates the continued execution of this instrumented code.

The amount of instrumentation code added varies widely between tools. At one end of the scale, Memcheck adds

code to check every memory access and every value computed, making it run 10-50 times slower than natively. At the

other end of the spectrum, the minimal tool, called Nulgrind, adds no instrumentation at all and causes in total "only"

about a 4 times slowdown.

Valgrind simulates every single instruction your program executes. Because of this, the active tool checks, or proﬁles,

not only the code in your application but also in all supporting dynamically-linked libraries, including the C library,

graphical libraries, and so on.

If you’re using an error-detection tool, Valgrind may detect errors in system libraries, for example the GNU C or X11

libraries, which you have to use. You might not be interested in these errors, since you probably have no control

over that code. Therefore, Valgrind allows you to selectively suppress errors, by recording them in a suppressions

ﬁle which is read when Valgrind starts up. The build mechanism selects default suppressions which give reasonable

behaviour for the OS and libraries detected on your machine. To make it easier to write suppressions, you can use the

--gen-suppressions=yes option. This tells Valgrind to print out a suppression for each reported error, which

you can then copy into a suppressions ﬁle.

Using and understanding the Valgrind core

Different error-checking tools report different kinds of errors. The suppression mechanism therefore allows you to say

which tool or tool(s) each suppression applies to.

2.2. Getting started

First off, consider whether it might be beneﬁcial to recompile your application and supporting libraries with debugging

info enabled (the -g option). Without debugging info, the best Valgrind tools will be able to do is guess which function

a particular piece of code belongs to, which makes both error messages and proﬁling output nearly useless. With -g,

you’ll get messages which point directly to the relevant source code lines.

Another option you might like to consider, if you are working with C++, is -fno-inline. That makes it easier to

see the function-call chain, which can help reduce confusion when navigating around large C++ apps. For example,

debugging OpenOfﬁce.org with Memcheck is a bit easier when using this option. You don’t have to do this, but doing

so helps Valgrind produce more accurate and less confusing error reports. Chances are you’re set up like this already,

if you intended to debug your program with GNU GDB, or some other debugger. Alternatively, the Valgrind option

--read-inline-info=yes instructs Valgrind to read the debug information describing inlining information.

With this, function call chain will be properly shown, even when your application is compiled with inlining.

If you are planning to use Memcheck: On rare occasions, compiler optimisations (at -O2 and above, and sometimes

-O1) have been observed to generate code which fools Memcheck into wrongly reporting uninitialised value errors,

or missing uninitialised value errors. We have looked in detail into ﬁxing this, and unfortunately the result is that

doing so would give a further signiﬁcant slowdown in what is already a slow tool. So the best solution is to turn off

optimisation altogether. Since this often makes things unmanageably slow, a reasonable compromise is to use -O.

This gets you the majority of the beneﬁts of higher optimisation levels whilst keeping relatively small the chances of

false positives or false negatives from Memcheck. Also, you should compile your code with -Wall because it can

identify some or all of the problems that Valgrind can miss at the higher optimisation levels. (Using -Wall is also a

good idea in general.) All other tools (as far as we know) are unaffected by optimisation level, and for proﬁling tools

like Cachegrind it is better to compile your program at its normal optimisation level.

Valgrind understands the DWARF2/3/4 formats used by GCC 3.1 and later. The reader for "stabs" debugging format

(used by GCC versions prior to 3.1) has been disabled in Valgrind 3.9.0.

When you’re ready to roll, run Valgrind as described above. Note that you should run the real (machine-code)

executable here. If your application is started by, for example, a shell or Perl script, you’ll need to modify it to

invoke Valgrind on the real executables. Running such scripts directly under Valgrind will result in you getting error

reports pertaining to /bin/sh, /usr/bin/perl, or whatever interpreter you’re using. This may not be what you

want and can be confusing. You can force the issue by giving the option --trace-children=yes, but confusion

is still likely.

2.3. The Commentary

Valgrind tools write a commentary, a stream of text, detailing error reports and other signiﬁcant events. All lines in

the commentary have following form:

==12345== some-message-from-Valgrind

The 12345 is the process ID. This scheme makes it easy to distinguish program output from Valgrind commentary,

and also easy to differentiate commentaries from different processes which have become merged together, for whatever

reason.

Using and understanding the Valgrind core

By default, Valgrind tools write only essential messages to the commentary, so as to avoid ﬂooding you with

information of secondary importance. If you want more information about what is happening, re-run, passing the -v

option to Valgrind. A second -v gives yet more detail.

You can direct the commentary to three different places:

1. The default: send it to a ﬁle descriptor, which is by default 2 (stderr). So, if you give the core no options, it will

write commentary to the standard error stream. If you want to send it to some other ﬁle descriptor, for example

number 9, you can specify --log-fd=9.

This is the simplest and most common arrangement, but can cause problems when Valgrinding entire trees of

processes which expect speciﬁc ﬁle descriptors, particularly stdin/stdout/stderr, to be available for their own use.

2. A less intrusive option is to write the commentary to a ﬁle, which you specify by --log-file=filename.

There are special format speciﬁers that can be used to use a process ID or an environment variable name in the log

ﬁle name. These are useful/necessary if your program invokes multiple processes (especially for MPI programs).

See the basic options section for more details.

3. The least intrusive option is to send the commentary to a network socket. The socket is speciﬁed as an IP address

and port number pair, like this: --log-socket=192.168.0.1:12345 if you want to send the output to host

IP 192.168.0.1 port 12345 (note: we have no idea if 12345 is a port of pre-existing signiﬁcance). You can also omit

the port number: --log-socket=192.168.0.1, in which case a default port of 1500 is used. This default is

deﬁned by the constant VG_CLO_DEFAULT_LOGPORT in the sources.

Note, unfortunately, that you have to use an IP address here, rather than a hostname.

Writing to a network socket is pointless if you don’t have something listening at the other end. We provide a simple

listener program, valgrind-listener, which accepts connections on the speciﬁed port and copies whatever

it is sent to stdout. Probably someone will tell us this is a horrible security risk. It seems likely that people will

write more sophisticated listeners in the fullness of time.

valgrind-listener can accept simultaneous connections from up to 50 Valgrinded processes. In front of

each line of output it prints the current number of active connections in round brackets.

valgrind-listener accepts three command-line options:

-e --exit-at-zero

When the number of connected processes falls back to zero, exit. Without this, it will run forever, that is, until you

send it Control-C.

--max-connect=INTEGER

By default, the listener can connect to up to 50 processes. Occasionally, that number is too small. Use this option

to provide a different limit. E.g. --max-connect=100.

Using and understanding the Valgrind core

portnumber

Changes the port it listens on from the default (1500). The speciﬁed port must be in the range 1024 to 65535. The

same restriction applies to port numbers speciﬁed by a --log-socket to Valgrind itself.

If a Valgrinded process fails to connect to a listener, for whatever reason (the listener isn’t running, invalid or

unreachable host or port, etc), Valgrind switches back to writing the commentary to stderr. The same goes for

any process which loses an established connection to a listener. In other words, killing the listener doesn’t kill the

processes sending data to it.

Here is an important point about the relationship between the commentary and proﬁling output from tools. The

commentary contains a mix of messages from the Valgrind core and the selected tool. If the tool reports errors, it will

report them to the commentary. However, if the tool does proﬁling, the proﬁle data will be written to a ﬁle of some

kind, depending on the tool, and independent of what --log-

options are in force. The commentary is intended

to be a low-bandwidth, human-readable channel. Proﬁling data, on the other hand, is usually voluminous and not

meaningful without further processing, which is why we have chosen this arrangement.

2.4. Reporting of errors

When an error-checking tool detects something bad happening in the program, an error message is written to the

commentary. Here’s an example from Memcheck:

==25832== Invalid read of size 4

==25832== at 0x8048724: BandMatrix::ReSize(int, int, int) (bogon.cpp:45)

==25832== by 0x80487AF: main (bogon.cpp:66)

==25832== Address 0xBFFFF74C is not stack’d, malloc’d or free’d

This message says that the program did an illegal 4-byte read of address 0xBFFFF74C, which, as far as Memcheck

can tell, is not a valid stack address, nor corresponds to any current heap blocks or recently freed heap blocks. The

read is happening at line 45 of bogon.cpp, called from line 66 of the same ﬁle, etc. For errors associated with

an identiﬁed (current or freed) heap block, for example reading freed memory, Valgrind reports not only the location

where the error happened, but also where the associated heap block was allocated/freed.

Valgrind remembers all error reports. When an error is detected, it is compared against old reports, to see if it is a

duplicate. If so, the error is noted, but no further commentary is emitted. This avoids you being swamped with

bazillions of duplicate error reports.

If you want to know how many times each error occurred, run with the -v option. When execution ﬁnishes, all the

reports are printed out, along with, and sorted by, their occurrence counts. This makes it easy to see which errors have

occurred most frequently.

Errors are reported before the associated operation actually happens. For example, if you’re using Memcheck and

your program attempts to read from address zero, Memcheck will emit a message to this effect, and your program will

then likely die with a segmentation fault.

In general, you should try and ﬁx errors in the order that they are reported. Not doing so can be confusing. For

example, a program which copies uninitialised values to several memory locations, and later uses them, will generate

several error messages, when run on Memcheck. The ﬁrst such error message may well give the most direct clue to

the root cause of the problem.

The process of detecting duplicate errors is quite an expensive one and can become a signiﬁcant performance overhead

if your program generates huge quantities of errors. To avoid serious problems, Valgrind will simply stop collecting

errors after 1,000 different errors have been seen, or 10,000,000 errors in total have been seen. In this situation you

might as well stop your program and ﬁx it, because Valgrind won’t tell you anything else useful after this. Note that

Using and understanding the Valgrind core

the 1,000/10,000,000 limits apply after suppressed errors are removed. These limits are deﬁned in m_errormgr.c

and can be increased if necessary.

To avoid this cutoff you can use the --error-limit=no option. Then Valgrind will always show errors, regardless

of how many there are. Use this option carefully, since it may have a bad effect on performance.

2.5. Suppressing errors

The error-checking tools detect numerous problems in the system libraries, such as the C library, which come pre-

installed with your OS. You can’t easily ﬁx these, but you don’t want to see these errors (and yes, there are many!)

So Valgrind reads a list of errors to suppress at startup. A default suppression ﬁle is created by the ./configure

script when the system is built.

You can modify and add to the suppressions ﬁle at your leisure, or, better, write your own. Multiple suppression ﬁles

are allowed. This is useful if part of your project contains errors you can’t or don’t want to ﬁx, yet you don’t want to

continuously be reminded of them.

Note: By far the easiest way to add suppressions is to use the --gen-suppressions=yes option described in

Core Command-line Options. This generates suppressions automatically. For best results, though, you may want to

edit the output of --gen-suppressions=yes by hand, in which case it would be advisable to read through this

section.

Each error to be suppressed is described very speciﬁcally, to minimise the possibility that a suppression-directive

inadvertently suppresses a bunch of similar errors which you did want to see. The suppression mechanism is designed

to allow precise yet ﬂexible speciﬁcation of errors to suppress.

If you use the -v option, at the end of execution, Valgrind prints out one line for each used suppression, giving the

number of times it got used, its name and the ﬁlename and line number where the suppression is deﬁned. Depending

on the suppression kind, the ﬁlename and line number are optionally followed by additional information (such as the

number of blocks and bytes suppressed by a memcheck leak suppression). Here’s the suppressions used by a run of

valgrind -v --tool=memcheck ls -l:

--1610-- used_suppression: 2 dl-hack3-cond-1 /usr/lib/valgrind/default.supp:1234

--1610-- used_suppression: 2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a /usr/lib/valgrind/default.supp:1234

Multiple suppressions ﬁles are allowed. Valgrind loads suppression patterns from $PREFIX/lib/valgrind/default.supp

unless --default-suppressions=no has been speciﬁed. You can ask to add suppressions from additional

ﬁles by specifying --suppressions=/path/to/file.supp one or more times.

If you want to understand more about suppressions, look at an existing suppressions ﬁle whilst reading the following

documentation. The ﬁle glibc-2.3.supp, in the source distribution, provides some good examples.

Each suppression has the following components:

• First line: its name. This merely gives a handy name to the suppression, by which it is referred to in the summary

of used suppressions printed out when a program ﬁnishes. It’s not important what the name is; any identifying

string will do.

剩余371页未读，继续阅读

qq_36235279

粉丝: 3
资源: 33

Valgrind快速入门指南：3.12版

valgrind-3.15.0-manual.pdf

valgrind_manual.pdf

valgrind_manual

valgrind使用，PPT

怎么在valgrind的官网下载valgrind

valgrind安装与使用

valgrind修改配置文件

linu 如何使用Valgrind

Valgrind的安装步骤

linux系统安装valgrind

最新资源