forked from ims0/comTutor
-
Notifications
You must be signed in to change notification settings - Fork 0
/
valgrind.quse
352 lines (320 loc) · 15.7 KB
/
valgrind.quse
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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
Algo-Uni-Rhythm-Verse
In a universe neatly intertwined with, and run rhythmically by logical algorithms...
Thursday, September 3, 2015
There comes a time in life of a developer when one gets this error
valgrind: failed to start tool 'memcheck' for platform 'x86-linux'
I do not see myself as an expert Valgrind user, but I understand output of Valgrind enough to catch memory leaks in my C programs.
The other day I launched a personal project in assembly language and used standard C memory routines (calloc, realloc, free) for its
memory requirements. The program grew complex and I wanted to be sure I am not leaking any memory (and also to be sure I am
leaking memory where I know I am leaking at that stage - amid development), and was also driven by the curiosity to see how well
Valgrind handled a program written in Assembly. After all, I have had never used Valgrind before for program written in any language
other than C.
So I launched Valgrind like so, and got that error - completely unexpected:
$
$ valgrind ./atail32_80 test.txt
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory
$
Thought never crossed my mind that the error was due to Assembly language front-end - and I was on the right track with that!
I hypothesized that the error was due to the fact that the program being debugged was a 32-bit program* on a 64-bit platform
(see below).
$
$ uname -i
x86_64
$ file ./atail32_80
./atail32_80: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xf3e3af4712a9382cb2b793f580a26a6797d64d1f, not stripped
$
*I was building that program as a 32-bit executable on purpose (further discussion about that would be irrelevant to this post).
I launched an investigation console and performed this small experiment to confirm my hypothesis.
$ echo "void main(){}" > testme.c
$
$ gcc -m32 -o testme32 testme.c
$
$ gcc -m64 -o testme64 testme.c
$
$ file testme32
testme32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x305f621662204c0289ee57e927c0221af84e4597, not stripped
$
$ file testme64
testme64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x285da18d5e71346dfd958b260fccfe3717cd2b99, not stripped
$
$ valgrind ./testme64
==28701== Memcheck, a memory error detector
==28701== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==28701== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==28701== Command: ./testme64
==28701==
==28701==
==28701== HEAP SUMMARY:
==28701== in use at exit: 0 bytes in 0 blocks
==28701== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==28701==
==28701== All heap blocks were freed -- no leaks are possible
==28701==
==28701== For counts of detected and suppressed errors, rerun with: -v
==28701== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
$
$ valgrind ./testme32
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory
The same error message on the last line above confirmed the cause of the error; but what was happening really ?
Knowing some tools helps; strace seemed liked the right one at this moment.
$
$ strace -e trace=file valgrind ./testme32
execve("/usr/bin/valgrind", ["valgrind", "./testme32"], [/* 67 vars */]) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("./testme32", O_RDONLY) = 3
readlink("/proc/self/exe", "/usr/bin/valgrind", 4096) = 17
execve("/usr/lib64/valgrind/memcheck-x86-linux", ["valgrind", "./testme32"], [/* 68 vars */]) = -1 ENOENT (No such file or directory)
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory
+++ exited with 1 +++
$
The execve() line just above the error message, that is now familiar to us, gives it away. Valgrind is trying to launch
/usr/lib64/valgrind/memcheck-x86-linux which seems to be missing.
Let us confirm:
$
$ ls /usr/lib64/valgrind/memcheck*
/usr/lib64/valgrind/memcheck-amd64-linux /usr/lib64/valgrind/memcheck-x86-linux
$
It is there ! But the file IS there - and at the very location expected by Valgrind ! Then why the failure ?
Wait, before concluding, recall that on *nix, we have all learned either the hard or the soft way, "When in doubt, think symbolic link".
On those lines:
$
$ cd /usr/lib64/valgrind/
$
$ pwd
/usr/lib64/valgrind
$
$ ls -l memcheck*
-rwxr-xr-x. 1 root root 3449056 Apr 25 2013 memcheck-amd64-linux
lrwxrwxrwx. 1 root root 37 Jun 10 04:42 memcheck-x86-linux -> ../../lib/valgrind/memcheck-x86-linux
$
$ ls -l ../../lib/valgrind/memcheck-x86-linux
ls: cannot access ../../lib/valgrind/memcheck-x86-linux: No such file or directory
$
So, memcheck-86-linux is indeed a symbolic link, and the target of which is missing.
Looking further, we can confirm that symbolic link /usr/lib64/valgrind/memcheck-x86-linux is created by/belongs to Valgrind package.
No surprises there!
$
$ yum provides /usr/lib64/valgrind/memcheck-x86-linux
Loaded plugins: langpacks, refresh-packagekit
google-chrome/filelists | 1.8 kB 00:00:00
1:valgrind-3.8.1-15.fc19.x86_64 : Tool for finding memory management bugs in programs
Repo : fedora
Matched from:
Filename : /usr/lib64/valgrind/memcheck-x86-linux
1:valgrind-3.8.1-15.fc19.x86_64 : Tool for finding memory management bugs in programs
Repo : installed
Matched from:
Filename : /usr/lib64/valgrind/memcheck-x86-linux
$
Digging further, we find that two memcheck* symbolic links created by valgrind.x86_64 are broken.
$
$ rpm -ql valgrind | grep memcheck
/usr/lib64/valgrind/memcheck-amd64-linux
/usr/lib64/valgrind/memcheck-x86-linux
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so
$
$
$ rpm -ql valgrind | grep memcheck | xargs file
/usr/lib64/valgrind/memcheck-amd64-linux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=0x82b75aa9e8494556aa050869e5e7ed20e9522137, stripped
/usr/lib64/valgrind/memcheck-x86-linux: broken symbolic link to `../../lib/valgrind/memcheck-x86-linux'
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xdd994ac2a32bece59363fadc2003e49a1b8c3539, stripped
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so: broken symbolic link to `../..
/lib/valgrind/vgpreload_memcheck-x86-linux.so'
$
Let us continue the expedition and find out what other Valgrind packages are available that could possibly bring in the missing files
that those symbolic links are pointing to:
$
$ yum list valgrind*
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
valgrind.x86_64 1:3.8.1-15.fc19 installed
Available Packages
valgrind.i686 1:3.8.1-15.fc19 fedora
valgrind-devel.i686 1:3.8.1-15.fc19 fedora
valgrind-devel.x86_64 1:3.8.1-15.fc19 fedora
valgrind-openmpi.x86_64 1:3.8.1-15.fc19 fedora
$
It is evident that we have 64-bit Valgrind package installed on the system, and 32-bit counter part of the Valgrind package is available (but
not installed on the system).
The solution to my problem seems within arm's reach - Install the package valgrind.i686
But I want to confirm two things before I install that package.
(a) valgrind.i686 will bring in (at least) those two missing files
(b) valgrind.i686 will not overwrite important valgrind binaries with 32-bit versions and break testing of my 64-bit executables.
Let us confirm (a) first:
$
$ repoquery -l valgrind.i686 | grep memcheck
/usr/lib/valgrind/memcheck-x86-linux
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so
$
Sure, the targets of those two broken symbolic link matches the path and file names of these two files.
That confirms that valgrind.i686 will bring in missing files.
Now, let us confirm (b):
$
$ repoquery -l valgrind.x86_64 | grep bin
/usr/bin/callgrind_annotate
/usr/bin/callgrind_control
/usr/bin/cg_annotate
/usr/bin/cg_diff
/usr/bin/cg_merge
/usr/bin/ms_print
/usr/bin/valgrind
/usr/bin/valgrind-listener
/usr/bin/vgdb
$
$ repoquery -l valgrind.i686 | grep bin
/usr/bin/callgrind_annotate
/usr/bin/callgrind_control
/usr/bin/cg_annotate
/usr/bin/cg_diff
/usr/bin/cg_merge
/usr/bin/ms_print
/usr/bin/valgrind
/usr/bin/valgrind-listener
/usr/bin/vgdb
$
$ repoquery -l valgrind.x86_64 | grep bin | xargs file
/usr/bin/callgrind_annotate: Perl script, ASCII text executable
/usr/bin/callgrind_control: Perl script, ASCII text executable
/usr/bin/cg_annotate: Perl script, ASCII text executable
/usr/bin/cg_diff: Perl script, ASCII text executable
/usr/bin/cg_merge: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x5228b41ce865c922a7948698c40a6ed1b7c7cf1c, stripped
/usr/bin/ms_print: Perl script, ASCII text executable
/usr/bin/valgrind: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x19186524e13c9eaaacdc8bec0144b3d82bb0800a, stripped
/usr/bin/valgrind-listener: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x5c9a1aa7055c71fcb7cab739509940deb4594464, stripped
/usr/bin/vgdb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xcbcdb0a010739b8ebfbff0abd508683987646c30, stripped
$
That seems like an issue.
There are duplicate executable files between the 64-bit and 32-bit versions, four of which are binary files.
I estimated - at worst, 32-bit package would overwrite these binary files and, as anticipated, break testing of 64-bit executables; but the damage would be easily reversible with two steps: (a) Uninstall valgrind.i686 (b) Reinstall valgrind.x86_64
With that I was ready to plunge on with a plan - If things broke, I would to make copy of those two symbolic link's target files, uninstall 32-bit package, reinstall 64-bit package, and finally manually restore broken symbolic links to fix the issue I originally started with.
So I did (sudo yum install valgrind.i686), and as it happens so, valgrind.i686 does not overwrite 64-bit executables.
$
$ rpm -ql valgrind.i686 | grep bin | xargs file
/usr/bin/callgrind_annotate: Perl script, ASCII text executable
/usr/bin/callgrind_control: Perl script, ASCII text executable
/usr/bin/cg_annotate: Perl script, ASCII text executable
/usr/bin/cg_diff: Perl script, ASCII text executable
/usr/bin/cg_merge: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x5228b41ce865c922a7948698c40a6ed1b7c7cf1c, stripped
/usr/bin/ms_print: Perl script, ASCII text executable
/usr/bin/valgrind: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x19186524e13c9eaaacdc8bec0144b3d82bb0800a, stripped
/usr/bin/valgrind-listener: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x5c9a1aa7055c71fcb7cab739509940deb4594464, stripped
/usr/bin/vgdb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xcbcdb0a010739b8ebfbff0abd508683987646c30, stripped
$
I can not explain this behaviour at this stage without looking into .rpm packaging script logic of this package.
Let us see if rest is as expected. Let us confirm that broken symbolic links are repaired:
$
$ rpm -ql valgrind.x86_64 | grep memcheck | xargs file
/usr/lib64/valgrind/memcheck-amd64-linux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=0x82b75aa9e8494556aa050869e5e7ed20e9522137, stripped
/usr/lib64/valgrind/memcheck-x86-linux: symbolic link to `../../lib/valgrind/memcheck-x86-linux'
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xdd994ac2a32bece59363fadc2003e49a1b8c3539, stripped
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so: symbolic link to `../../lib/valgrind/vgpreload_memcheck-x86-linux.so'
$
Sure they are.
Now, like you I was curious to see if valgrind could test 32-bit executables now (without breaking 64-bit executables tests):
$
$ valgrind ./testme32
==7914== Memcheck, a memory error detector
==7914== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7914== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7914== Command: ./testme32
==7914==
==7914==
==7914== HEAP SUMMARY:
==7914== in use at exit: 0 bytes in 0 blocks
==7914== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==7914==
==7914== All heap blocks were freed -- no leaks are possible
==7914==
==7914== For counts of detected and suppressed errors, rerun with: -v
==7914== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$
$ valgrind ./testme64
==8176== Memcheck, a memory error detector
==8176== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==8176== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==8176== Command: ./testme64
==8176==
==8176==
==8176== HEAP SUMMARY:
==8176== in use at exit: 0 bytes in 0 blocks
==8176== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==8176==
==8176== All heap blocks were freed -- no leaks are possible
==8176==
==8176== For counts of detected and suppressed errors, rerun with: -v
==8176== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
$
Good. Valgrind is now capable to test both: 64-bit as well as 32-bit executables.
$ valgrind ./atail32_80 test.txt
<snip>
==13468==
==13468== HEAP SUMMARY:
==13468== in use at exit: 266 bytes in 10 blocks
==13468== total heap usage: 18 allocs, 8 frees, 623 bytes allocated
==13468==
==13468== LEAK SUMMARY:
==13468== definitely lost: 262 bytes in 9 blocks
<snip>
Testing my project binary with valgrind did catch expected memory leaks on the first run, along with couple of unexpected memory
access related bugs (not shown here). Now that is going to keep me busy for some time.
Leave any comments/suggestions below.
Posted by Bijal Thanawala at 7:58 PM
Email This
BlogThis!
Share to Twitter
Share to Facebook
Share to Pinterest
Labels: debugging, development, memory leak, rpm, strace, valgrind, yum
No comments:
Post a Comment
Newer Post Older Post Home
Subscribe to: Post Comments (Atom)
Labels
development linux build kernel Makefile command-line debugging memory leak rm rpm strace valgrind version yum
Total Pageviews
0 30
1 40
2 20
3 10
4 0
5 10
6 10
7 20
8 30
9 30
10 10
11 0
12 10
13 0
14 30
15 20
16 10
17 50
18 10
19 0
20 20
21 30
22 40
23 0
24 70
25 0
26 0
27 30
28 80
29 10
494
Blog Archive
▼ 2015 (4)
► Oct (2)
▼ Sep (1)
valgrind: failed to start tool 'memcheck' for plat...
► Jun (1)
About Me
My photo
Bijal Thanawala
View my complete profile
Awesome Inc. theme. Powered by Blogger.