Valgrind SpyGlass官方手册3.2.3版：快速入门与详解

需积分: 5 4 浏览量更新于2024-06-25 1 收藏 1.02MB PDF 举报

Valgrind Manual 是一份官方文档，详细介绍了 SpyGlass（Valgrind）这一强大的内存调试和性能分析工具。Valgrind 是一个用于Linux、Mac OS X和某些其他Unix系统上的动态代码分析器，主要用于检测C/C++程序中的内存错误，如内存泄漏、悬挂指针、野指针访问等。该版本是3.2.329，发布于2007年1月，由 Valgrind 开发者团队维护，其版权遵循 GNU Free Documentation License（v1.2或更高版本）。文档分为几个主要部分： 1. **Valgrind Quick Start Guide**：这是一个快速入门指南，适合初次接触Valgrind的新手。它包括： - **Introduction**：简要介绍Valgrind及其在软件开发中的作用。 - **Preparing your program**：指导如何准备要测试的程序，确保其能被Valgrind正确运行。 - **Running your program under Memcheck**：详细介绍如何在Memcheck模式下运行程序，这是Valgrind的主要功能之一。 - **Interpreting Memcheck's output**：解释如何解析和理解Memcheck产生的报告，以识别和修复内存问题。 - **Caveats**：列出可能遇到的一些限制和注意事项，帮助用户避免常见误解。 - **More information**：提供进一步学习和深入使用的链接和资源。 2. **Valgrind User Manual**：更详尽的用户手册，涵盖Valgrind的其他工具如Callgrind（性能分析）、LeakSanitizer（内存泄漏检测）和C/C++代码质量检查工具（如Clang tools），以及高级用法和技术细节。 3. **Valgrind FAQ**：解答关于Valgrind使用过程中常见的问题，帮助用户解决实际操作中的疑问。 4. **Valgrind Technical Documentation**：包含技术规格、API文档和开发者指南，适用于对Valgrind源码有深入研究的开发者。 5. **Valgrind Distribution Documents**：与Valgrind的安装、配置和更新相关的文档。 6. **GNULicenses**：包含了GNU许可证信息，确保用户了解并遵守Valgrind软件的开源许可协议。这份文档是Valgrind用户的宝贵资源，无论是软件开发人员、质量保证工程师还是系统管理员，都能从中获取到所需的信息来有效地检测和改进代码的质量和性能。

Using and understanding the Valgrind core

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.

Note carefully that the commentary is

not written to the ﬁle you specify, but instead to one called

filename.12345, if for example the pid of the traced process is 12345. This is helpful when val-

grinding a whole tree of processes at once, since it means that each process writes to its own logﬁle, rather than

the result being jumbled up in one big logﬁle. If filename.12345 already exists, then it will name new ﬁles

filename.12345.1 and so on.

If you want to specify precisely the ﬁle name to use, without the trailing .12345 part, you can instead use

--log-file-exactly=filename.

You can also use the --log-file-qualifier=<VAR> option to modify the ﬁlename via according to the

environment variable VAR. This is rarely needed, but very useful in certain circumstances (eg. when running

MPI programs). In this case, the trailing

.12345 part is replaced by the contents of $VAR. The idea is that

you specify a variable which will be set differently for each process in the job, for example BPROC_RANK or

whatever is applicable in your MPI setup.

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 (I 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 pretty useless 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 two command-line ﬂags:

• -e or --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.

• 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.

Using and understanding the Valgrind core

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 one of the error-checking tools (Memcheck, Helgrind) detects something bad happening in the program, an

error message is written to the commentary. For example:

==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 currently malloc’d or free’d 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

malloc’d/free’d block, for example reading free’d memory, Valgrind reports not only the location where the error

happened, but also where the associated block was malloc’d/free’d.

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. If you’re using a tool (Memcheck) which does

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

the program will then duly 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 1000 different errors have been seen, or 10000000 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

the 1000/10000000 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 ﬂag. Then Valgrind will always show errors, regardless

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

2.5. Suppressing errors

Using and understanding the Valgrind core

The error-checking tools detect numerous problems in the base libraries, such as the GNU C library, and the XFree86

client libraries, which come pre-installed on your GNU/Linux system. 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 cooked up 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 ﬂag described in

Command-line ﬂags for the Valgrind core.

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

inadvertantly 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 ﬂag, at the end of execution, Valgrind prints out one line for each used suppression, giving its name

and the number of times it got used. Here’s the suppressions used by a run of valgrind --tool=memcheck

ls l:

--27579-- supp: 1 socketcall.connect(serv_addr)/__libc_connect/__nscd_getgrgid_r

--27579-- supp: 1 socketcall.connect(serv_addr)/__libc_connect/__nscd_getpwuid_r

--27579-- supp: 6 strrchr/_dl_map_object_from_fd/_dl_map_object

Multiple suppressions ﬁles are allowed. By default, Valgrind uses $PREFIX/lib/valgrind/default.supp.

You can ask to add suppressions from another ﬁle, by specifying --suppressions=/path/to/file.supp.

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

documentation. The ﬁle glibc-2.2.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.

• 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 (Nb: 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 ﬁle.

Valgrind’s core can detect certain PThreads API errors, for which this line reads:

core:PThread

Using and understanding the Valgrind core

• 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 four of these lines.

Locations may be either names of shared objects/executables or wildcards matching function names. They begin

obj: and fun: respectively. Function and object names to match against may use the wildcard characters

and ?.

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.

• Finally, the entire suppression must be between curly braces. Each brace must be the ﬁrst 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:

{

__gconv_transform_ascii_internal/__mbrtowc/mbtowc

Memcheck:Value4

fun:__gconv_transform_ascii_internal

fun:__mbr

toc

fun:mbtowc

}

What it means is: for Memcheck only, suppress a use-of-uninitialised-value error, when the data size

is 4, when it occurs in the function __gconv_transform_ascii_internal, when that is called

from any function of name matching __mbr

toc, when that is called from mbtowc. It doesn’t ap-

ply under any other circumstances. The string by which this suppression is identiﬁed to the user is

__gconv_transform_ascii_internal/__mbrtowc/mbtowc.

(See Writing suppression ﬁles for more details on the speciﬁcs of Memcheck’s suppression kinds.)

Another example, again for the Memcheck tool:

{

libX11.so.6.2/libX11.so.6.2/libXaw.so.7.0

Memcheck:Value4

obj:/usr/X11R6/lib/libX11.so.6.2

obj:/usr/X11R6/lib/libXaw.so.7.0

}

Suppress any size 4 uninitialised-value error which occurs anywhere in libX11.so.6.2, when called from

anywhere in the same library, when called from anywhere in

libXaw.so.7.0. The inexact speciﬁcation of

locations is regrettable, but is about all you can hope for, given that the X11 libraries shipped with Red Hat 7.2 have

had their symbol tables removed.

Note: since the above two examples did not make it clear, you can freely mix the obj: and fun: styles of description

within a single suppression record.

2.6. Command-line ﬂags for the Valgrind core

剩余216页未读，继续阅读

滕杰

粉丝: 8
资源: 191

Valgrind SpyGlass官方手册3.2.3版：快速入门与详解

Valgrind 3.15.0官方文档：快速入门与完整指南

深入解析asan_symbolize.py：ASan符号化工具应用

压缩文件dump_info.tar.gz的解析与还原指南

valgrind-3.15.0-manual.pdf

valgrind manual

Valgrind使用手册

linux平台下内存泄漏检测工具valgrind3.11

GUN C （The GNU C Library Reference Manual）

CentOS下Valgrind安装与内存泄漏检测教程

Redis键值数据库深入源码分析与性能测试实现

最新资源