|
From: Marian K. <in...@se...> - 2004-12-02 10:53:36
|
To whom it may concern.
For almost half a year, I had a great problem with Valgrind. It refused to
print out line #´s of leaks and memory errors in my program - which, of course,
is a crucial problem. No magic around -g, -gstabs etc. helped; and, strangely,
the problem manifestated on various Linux distributions, like SuSE 9.2,
Mandrake 9.2, Mandrake 10.1, with various variants of gcc/g++, ranging from
2.96 to 3.4.1. I still experimented with this issue, which took me some 80
hours of work, if not more.
Then, just a few days ago, I created a short program performing a memory leak,
and Valgrind WORKED on it, giving the correct line numbers - to my great
wonder.
I tried to run Valgrind on my program again (which is Multiple Polynomial
Quadratic Sieve, for those interested in cryptography), and the line #s were
gone again; so, I thought that the reason might be in some imported library,
like GMP, and experimented on.
To my great bewilderment, when I copied the primitive leak.c file to the
directory where my MPQS sources lie, Valgrind STOPPED working on it and the
output was again cryptic, full of ???s and no line numbers given; this
seemed
very strange to me, since I almost never met a program which would worked in
some directories and not in other ones. Then, I realized that there is a subtle
difference in the directories: as an ex-Windows freak, I often use paths
containing SPACES. Could this be the reason? I prepared a small experiment that
supported this conjecture.
At first, I took an extremely short program named leak.c, whose source code is
here:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[]) {
int* a = (int*) malloc(10*sizeof(int));
printf("%d",a[10]);
return 0;
}
It demonstrates 2 errors: a wrong read access a[10] and a memory leak given
by
not freeing the "a" pointer. Valgrind should be able to detect both errors.
Then, in my home directory, I created two subdirectories, one named "Valgrind"
and the other named "Valgrind experiments". I copied leak.c into both
directories, compiled it with command
gcc -g leak.c
and run
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./a.out
The output from directory Valgrind was totally correct, as follows:
==7736== Invalid read of size 4
==7736== at 0x8048415: main (leak.c:6)
==7736== Address 0x1BA41050 is 0 bytes after a block of size 40 alloc'd
==7736== at 0x1B903E74: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==7736== by 0x804840B: main (leak.c:5)
0==7736==
==7736== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1)
==7736== malloc/free: in use at exit: 40 bytes in 1 blocks.
==7736== malloc/free: 1 allocs, 0 frees, 40 bytes allocated.
==7736== For counts of detected errors, rerun with: -v
==7736== searching for pointers to 1 not-freed blocks.
==7736== checked 1286432 bytes.
==7736==
==7736==
==7736== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7736== at 0x1B903E74: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==7736== by 0x804840B: main (leak.c:5)
On the other hand, in "Valgrind experiments" directory, the output was bad,
showing no line numbers:
==7679==
==7679== Invalid write of size 1
==7679== at 0x8048828: ???
==7679== by 0x1BA6EB0F: __libc_start_main (in /lib/tls/libc.so.6)
==7679== by 0x8048760: ???
==7679== Address 0x1BB7302A is 0 bytes after a block of size 2 alloc'd
==7679== at 0x1B903E74: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==7679== by 0x804881F: ???
==7679== by 0x1BA6EB0F: __libc_start_main (in /lib/tls/libc.so.6)
==7679== by 0x8048760: ???
==7679==
==7679== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 19 from 1)
==7679== malloc/free: in use at exit: 2 bytes in 1 blocks.
==7679== malloc/free: 31 allocs, 30 frees, 162 bytes allocated.
==7679== For counts of detected errors, rerun with: -v
==7679== searching for pointers to 1 not-freed blocks.
==7679== checked 2526500 bytes.
==7679==
==7679==
==7679== 2 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7679== at 0x1B903E74: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==7679== by 0x804881F: ???
==7679== by 0x1BA6EB0F: __libc_start_main (in /lib/tls/libc.so.6)
==7679== by 0x8048760: ???
So, valgrind 2.0.0 and 2.2.0 does not probably work correctly in directories
whose path includes a space.
Holy s***, that is what I call a bug :-) Is that a known problem? I did not
meet it in valgrind-users list.
|
|
From: Tom H. <th...@cy...> - 2004-12-02 11:06:45
|
In message <loo...@po...>
Marian Kechlibar <in...@se...> wrote:
> So, valgrind 2.0.0 and 2.2.0 does not probably work correctly in directories
> whose path includes a space.
>
> Holy s***, that is what I call a bug :-) Is that a known problem? I did not
> meet it in valgrind-users list.
Bug 88678.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|