Valgrind 3.15.0官方手册：快速入门与详细文档指南

需积分: 11 29 浏览量更新于2024-07-15 收藏 1.31MB PDF 举报

Valgrind-3.15.0的官方使用手册是一份详尽的文档，提供了对Valgrind这款强大的内存调试和性能分析工具的全面介绍。Valgrind是一个开源项目，由一组开发者维护，其版权许可遵循GNU自由文档许可证（GNU Free Documentation License, Version 1.2 或更高版本）。这份手册分为六个逻辑上独立的部分，旨在帮助用户快速上手和深入理解Valgrind。 1. **Valgrind快速入门指南**：这是手册的起点，为新用户提供了一个快速了解Valgrind如何工作的概览。它介绍了如何安装、配置和使用Valgrind进行基本的内存检测和性能分析，包括如何针对各种编程语言（如C/C++）编写测试程序，并展示了如何解析Valgrind的输出结果。 2. **Valgrind用户手册**：这是手册的核心部分，包含了详细的命令行选项、工具介绍、调试技巧和高级功能，是理解和掌握Valgrind的强大功能的关键。它涵盖了内存错误检测、CPU计时、数据缓存分析、线程跟踪等多个方面的内容，以及如何针对特定问题定制Valgrind的工作方式。 3. **Valgrind FAQ**：这部分解答了常见的用户疑问，提供了解决实际使用中遇到的问题的实用建议，有助于用户在遇到复杂情况时找到解决方案。 4. **Valgrind技术文档**：这部分深入探讨了Valgrind的内部工作原理和技术细节，适合对工具的底层实现感兴趣的开发者或高级用户阅读。 5. **Valgrind发行文档**：包含了关于软件的安装、更新、打包和构建等相关信息，帮助用户管理和维护Valgrind的本地安装。 6. **GNU许可信息**：最后，手册附带了完整的GNU Free Documentation License，确保用户在使用和传播文档时符合许可证要求。 Valgrind-3.15.0的官方使用手册是开发人员和系统管理员必备的工具，无论是初次接触Valgrind还是寻求更深层次的理解，都能从中获得宝贵的信息。通过这份手册，读者可以掌握如何有效地利用Valgrind来检测代码中的内存泄漏、数据竞争等错误，以及优化程序性能。

Using and understanding the Valgrind core

2.2. Getting started

First off, consider whether it might be beneficial 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 profiling 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 OpenOffice.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 fixing this, and unfortunately the result

is that doing so would give a further significant 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 benefits 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 profiling 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 significant 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.

By default, Valgrind tools write only essential messages to the commentary, so as to avoid flooding 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 file 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 file descriptor, for example

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

Using and understanding the Valgrind core

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

processes which expect specific file descriptors, particularly stdin/stdout/stderr, to be available for their own

use.

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

There are special format specifiers that can be used to use a process ID or an environment variable name in

the log file 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 specified 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 significance).

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 defined 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 specified 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.

portnumber

Changes the port it listens on from the default (1500). The specified port must be in the range 1024 to

65535. The same restriction applies to port numbers specified 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 profiling 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 profiling, the profile data will be written to a file

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. Profiling 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:

Using and understanding the Valgrind core

==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 file, etc. For errors associated

with an identified (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 finishes, 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 fix 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 first 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 significant 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 fix it, because Valgrind won't tell you anything else

useful after this. Note that the 1,000/10,000,000 limits apply after suppressed errors are removed. These limits are

defined 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 fix 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 file is created by the ./

configure script when the system is built.

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

files are allowed. This is useful if part of your project contains errors you can't or don't want to fix, 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 specifically, 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 flexible specification 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 filename and line number where the suppression is defined. Depending

Using and understanding the Valgrind core

on the suppression kind, the filename 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 files are allowed. Valgrind loads suppression patterns from $PREFIX/lib/valgrind/

default.supp unless --default-suppressions=no has been specified. You can ask to add

suppressions from additional files by specifying --suppressions=/path/to/file.supp one or more

times.

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

following documentation. The file 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 finishes. It's not important what the name is; any identifying

string will do.

• Second line: name of the tool(s) that the suppression is for (if more than one, comma-separated), and the name

of the suppression itself, separated by a colon (n.b.: no spaces are allowed), eg:

tool_name1,tool_name2:suppression_name

Recall that Valgrind is a modular system, in which different instrumentation tools can observe your program

whilst it is running. Since different tools detect different kinds of errors, it is necessary to say which tool(s) the

suppression is meaningful to.

Tools will complain, at startup, if a tool does not understand any suppression directed to it. Tools ignore

suppressions which are not directed to them. As a result, it is quite practical to put suppressions for all tools

into the same suppression file.

• Next line: a small number of suppression types have extra information after the second line (eg. the Param

suppression for Memcheck)

• Remaining lines: This is the calling context for the error -- the chain of function calls that led to it. There can

be up to 24 of these lines.

Locations may be names of either shared objects, functions, or source lines. They begin with obj:, fun:, or

src: respectively. Function, object, and file names to match against may use the wildcard characters * and ?.

Source lines are specified using the form filename[:lineNumber].

Important note: C++ function names must be mangled. If you are writing suppressions by hand, use the --

demangle=no option to get the mangled names in your error messages. An example of a mangled C++ name

is _ZN9QListView4showEv. This is the form that the GNU C++ compiler uses internally, and the form that

must be used in suppression files. The equivalent demangled name, QListView::show(), is what you see

at the C++ source code level.

A location line may also be simply "..." (three dots). This is a frame-level wildcard, which matches zero

or more frames. Frame level wildcards are useful because they make it easy to ignore varying numbers of

uninteresting frames in between frames of interest. That is often important when writing suppressions which

are intended to be robust against variations in the amount of function inlining done by compilers.

• Finally, the entire suppression must be between curly braces. Each brace must be the first character on its own

line.

A suppression only suppresses an error when the error matches all the details in the suppression. Here's an example:

剩余358页未读，继续阅读

Phoenix1428

粉丝: 0
资源: 1

Valgrind 3.15.0官方手册：快速入门与详细文档指南

valgrind_manual.pdf

valgrind_manual

内存检测valgrind-3.11.0.tar

valgrind-3.15.0.tar.bz2

valgrind安装详解

ubuntu valgrind

valgrind使用

valgrind中的命令使用用法

valgrind3.20

ubuntu安装valgrind

最新资源