-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathvalgrind-internal.html
102 lines (85 loc) · 4.23 KB
/
valgrind-internal.html
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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<link REL=stylesheet HREF=http://developer.r-project.org/Rtech.css>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Valgrind and the R memory manager</title>
<STYLE TYPE="text/css">
BODY { padding-left: 8%; padding-right: 8% }
</STYLE>
</head>
<body bgcolor="#FFFFFF">
<h1 align="center">Valgrind and the R memory manager</h1>
<a href="http://valgrind.org">Valgrind</a> is a set of tools for
detecting memory management bugs. Previously it ran only on x86 Linux,
but version 3.0 supports AMD64 Linux and support for FreeBSD and for
PowerPC Linux are under development.
Typically Valgrind is used with unmodified binaries. It runs the
binary in a CPU emulator and tracks memory allocations and
initialisations. This approach is limited when a program does its own
memory management. In R, memory becomes inaccessible to a correctly
functioning program when it is garbage collected, and integer, logical
and numeric vectors are uninitialized when allocated, but Valgrind does
not know this.<p>
Valgrind provides a `client request mechanism' for programs to provide
information about their own memory management. This has been added to
R-devel. There are four levels of instrumentation, governed by the
macro <tt>VALGRIND_LEVEL</tt>.
<ul> <li> <tt>VALGRIND_LEVEL = 0</tt> removes all Valgrind
instrumentation. This is currently the default
<li> <tt>VALGRIND_LEVEL = 1</tt> marks newly allocated numeric, integer,
and logical vectors as uninitialized, as if they had been obtained from
<tt>malloc</tt>. This allows Valgrind to catch use of uninitialized
variables. It will also catch some pointer protection bugs. If an
unprotected vector is garbage collected and the memory is reallocated to
a numeric, integer, or logical vector, and is read before being written,
Valgrind will report an uninitialized read. Level 1 imposes little
performance penalty on Valgrind and I hope it will become the default
for suitable platforms.
<li><tt>VALGRIND_LEVEL = 2</tt> also marks the DATAPTR() section of
each node as inaccessible when the node is garbage collected or when a
new page is obtained, and as accessible when it is allocated. This
catches quite a lot of potential bugs, but makes Valgrind run much
more slowly. The performance penalty seems smaller with Valgrind 3.0 on
AMD64.
<li> <tt>VALGRIND_LEVEL = 3</tt> marks the ATTRIB pointer and the first
three bytes of the SEXPREC_HEADER for all nodes, and the three words of
data in non-vector nodes as inaccessible on garbage collection and as
unitialised when first allocated.
</ul>
There is a configure option to set <tt>VALGRIND_LEVEL</tt>,
<pre>
configure --with-valgrind-instrumentation=## </pre>
where <tt>##</tt> can be 0, 1, 2, or 3. The default is 0. At the moment
there is no configuration check that the platform is compatible with
valgrind when a level > 0 is specified. Any problems will appear at
compile-time. The potential for problems occurs on x86 platforms other
than Win32 and Linux, and on PowerPC platforms other than Linux.<p>
Both levels of instrumentation will catch more bugs when used in
conjunction with <tt>gctorture(TRUE)</tt>. I have added targets
<tt>test-Valgrind</tt> and <tt>test-Vgct</tt> to
<tt>tests/Makefile</tt>. These run the same code as <tt>test-Gct</tt>
under Valgrind and Valgrind + gctorture() respectively. They report to
standard output all messages from Valgrind. <p>
It may be useful to add a fourth level of instrumentation to cover the
header fields of the memory nodes.<p>
<hr>
Running test-Gct and no-segfault.R under Valgrind has found five
bugs so far. One is purely theoretical (when using unary "!" with two
arguments). Two are briefly unprotected pointers that might
theoretically cause heisenbugs at some point. The final two are real,
if not terribly major: <tt>parse(,n=0)</tt> used a status variable
that was never set, and <tt>regexpr</tt> applied <tt>STRING_ELT</tt> to
the <tt>pattern</tt> argument before coercing it to a string, so that
<pre>
> regexpr(NA,"NANA")
[1] 1
attr(,"match.length")
[1] 2
> regexpr(as.character(NA),"NANA")
Error in regexpr(pattern, text, extended, fixed, useBytes) :
invalid argument
</pre>
<hr>
Thomas Lumley. 2005-8-9
<p>