Valgrind：Linux内存检测与线程调试实战指南

4星 · 超过85%的资源需积分: 31 176 浏览量更新于2024-07-31 1 收藏 1.1MB PDF 举报

"Valgrind 是一款强大的 Linux 系统下的内存检测和多线程调试工具，用于查找内存泄漏、管理锁和条件变量等问题。它提供了详细的诊断信息，包括调用关系图，帮助开发者深入理解程序的行为。Valgrind 文档分为多个部分，如快速入门指南、用户手册、常见问题解答和技术文档，便于用户逐步学习和使用。" Valgrind 是一个开源的模拟执行框架，主要功能是检测 C 和 C++ 程序中的内存错误和性能问题。它通过运行时分析来提供关于内存泄漏、无效指针和未初始化的内存访问等错误的详细报告。此外，Valgrind 还支持对多线程程序的调试，包括检查线程同步问题，如死锁和竞态条件。 **内存检测** Valgrind 的核心组件 Memcheck 可以有效地检测多种类型的内存错误： 1. **内存泄漏**：当程序分配的内存没有被正确释放时，Valgrind 能够跟踪这些内存块并报告泄漏。 2. **未初始化的内存读取和写入**：如果程序读取或写入未初始化的内存，Valgrind 将发出警告。 3. **非法内存访问**：检测访问已经释放的内存、越界数组访问等非法内存操作。 4. **悬挂指针**：检查不再指向有效内存的指针。 **线程调试** Valgrind 提供了 Helgrind 工具，专门用于检测多线程程序中的并发错误： 1. **死锁**：检测线程间的资源竞争导致的死锁情况。 2. **竞态条件**：识别线程之间对共享资源的不恰当同步。 3. **锁和条件变量的使用**：分析锁的获取和释放，以及条件变量的等待和唤醒是否正确。 **使用 Valgrind 的步骤** 1. **安装 Valgrind**：首先确保你的 Linux 系统上已经安装了 Valgrind。 2. **编译程序**：使用调试信息的编译选项（例如 -g）编译你的程序。 3. **运行 Valgrind**：通过命令行运行 Valgrind，并指定你的程序和参数。例如：`valgrind --tool=memcheck ./your_program` 4. **查看报告**：Valgrind 会输出详细的诊断信息，包括错误发生的位置和上下文。 5. **分析和修复问题**：根据报告定位和修复代码中的错误。 **Valgrind 的其他工具** 除了 Memcheck 和 Helgrind，Valgrind 还包含其他工具，如 Callgrind（用于性能分析和函数调用统计）和 Massif（内存堆分析器）。 **Valgrind 文档** 为了更好地使用 Valgrind，建议阅读官方提供的文档，包括快速入门指南，了解基本用法；用户手册，获取详细配置和选项信息；以及 FAQ，解答常见问题。 Valgrind 是 Linux 开发者不可或缺的工具，能够帮助他们找到和修复内存错误，优化多线程程序，提升软件质量和可靠性。

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.

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 both the older "stabs" debugging format, used by GCC versions prior to 3.1, and the newer

DWARF2/3/4 formats used by GCC 3.1 and later. We continue to develop our debug-info readers, although the

majority of effort will naturally enough go into the newer DWARF readers.

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.

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.

Using and understanding the Valgrind core

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 two command-line options:

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

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

Using and understanding the Valgrind core

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

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

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

Locations may be names of either shared objects or functions. 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. 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 ﬁles. 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 ﬁ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

}

This suppresses 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

剩余273页未读，继续阅读

tangyulong1214

粉丝: 9
资源: 4

Valgrind：Linux内存检测与线程调试实战指南

多线程性能测试工具(服务器压力测试)

JAVA多线程测试工具

内存泄露检测+锁管理

Windebug调试工具

GDB调试工具中文使用手册详解

Valgrind：Linux下高效内存检查与多线程同步工具

Linux下C语言内存泄漏检测工具推荐与分析

Linux下GDB调试完全手册

Valgrind：Linux内存调试与性能分析神器

Linux进程和线程调度机制详解

最新资源