|
From: Maddy <man...@gm...> - 2012-07-11 08:45:27
|
Downloaded the latest version, Valgrind 3.7.0, untarred it to create a folder
"Valgrind-3.7.0" Now, what I did was export gcc for compatibility with the
target machine and configured to disable tls and give the host. Also I made a C
Program "leak.c" and its object file "a.out" compiled with the following command
export CC=/usr/local/netd_tools_v1/powerpc/bin/powerpc-linux-gnu-gcc leak.c
so
a. export CC=/usr/local/netd_tools_v1/powerpc/bin/powerpc-linux-gnu-gcc
b. ./configure --prefix=/netd --host=powerpc-linux --disable-tls
c. make
d. make install
Link the library path and valgrind executable (go to /netd/lib and do ln –s
/u/netd/lib/valgrind THEN goto /netd/usr/sbin and do ln –s /u/netd/bin/valgrind)
Some files were made in "Valgrind-3.7.0" and a folder "netd" was formed. "netd"
contained "lib", "bin", "share" and "include"
(/netd/lib and /netd/usr/sbin are project specific directories)
Copied these files (files in "netd") into the Target Machine and ran Valgrind on
the file "a.out" by the following command :
valgrind --log-file=/u/july5.txt --leak-check=summary --tool=memcheck ./a.out
(/u is the mount point, july5 is the log file)
The output shows 0 leaks reported
int main()
{
printf("I am leaking.");
int *a =(int *) malloc(100);
return 0;
}
This ran on linux just fine and reported memory leaks. If this programme would
have worked on powerpc, then I would have run Valgrind on project specific
processes.
|
|
From: Philippe W. <phi...@sk...> - 2012-07-11 20:06:52
|
On Wed, 2012-07-11 at 08:05 +0000, Maddy wrote:
> The output shows 0 leaks reported
>
> int main()
> {
> printf("I am leaking.");
> int *a =(int *) malloc(100);
> return 0;
> }
>
> This ran on linux just fine and reported memory leaks. If this programme would
> have worked on powerpc, then I would have run Valgrind on project specific
> processes.
Does the output reports that there is still a block allocated ?
It is not abnormal to have the below not detected.
E.g. if a register keeps a copy of the value of a, then the leak search
of Valgrind will consider that the malloc-ed block is still reachable.
(note: in Valgrind 3.8.0, there is a new functionality which allows to
show why a block is still considered as reachable).
E.g. on my linux fedora12/x86, the below program
int main()
{
char *ch = (char*)malloc(sizeof(10));
ch = (void*)0x0;
}
also shows no leak, while clearly it leaks even more than yours.
However, it reports:
...
==2431== HEAP SUMMARY:
==2431== in use at exit: 4 bytes in 1 blocks
...
==2431== still reachable: 4 bytes in 1 blocks
If the output reports that there was no block ever allocated (and no
block still reachable), then it probably means that the malloc
function was not properly intercepted by Valgrind.
Use a bunch of -v, -d args together with --trace-redir=yes
to investigate what happens.
Philippe
|