Hello list.
I've been using valgrind -3.4.0 fpo ppc32 (powerquicc II) for some
time now and it has served me well.
Now I got valgring 3.6.0, compiled it and noticed that valdring does
not detect memory memory allocations, not complaining of memory leaks
that I deliberately created.
This is the configure line that I used.
For the record, I also tried adding CFLAGS=-gdwarf-2 , and
--enable-tls (one or the other or both) without any changes in
behaviour.
----8<---
./configure --prefix=/valgrind --host=powerpc-e300c3-linux
------8<------
Here's the gcc that I'm using. Unfortunately I am unable to rebuild a
toolchain for ths system I am working on and I have to stick with this
one:
-----8<-------
~$ powerpc-e300c3-linux-gcc --v
Using built-in specs.
Target: powerpc-e300c3-linux
Configured with:
/usr/src/redhat/BUILD/crosstool/source/gcc-4.0.2/configure
--target=powerpc-e300c3-linux --host=i686-host_pc-linux-gnu
--prefix=/opt/freescale/usr/local/gcc-4.0.2-glibc-2.3.6-nptl-2/powerpc-e300c3-linux
--with-cpu=e300c3 --enable-cxx-flags=-mcpu=e300c3
--with-headers=/opt/freescale/usr/local/gcc-4.0.2-glibc-2.3.6-nptl-2/powerpc-e300c3-linux/powerpc-e300c3-linux/include
--with-local-prefix=/opt/freescale/usr/local/gcc-4.0.2-glibc-2.3.6-nptl-2/powerpc-e300c3-linux/powerpc-e300c3-linux
--disable-nls --enable-threads=posix --enable-symvers=gnu
--enable-__cxa_atexit --enable-languages=c,c++ --enable-shared
--enable-c99 --enable-long-long
Thread model: posix
gcc version 4.0.2 20060628 (Wasabi)
----------8<---------
I created a very simple test program to check leak detections:
------8<-------
#include <stdlib.h>
int main(void)
{
char buf[1000] = malloc(1000;
buf[0] = 0;
return 0;
}
--------8<-------
and compiled it with pq2-gcc -o leak -O0 leaktest.c
(pq2-***) are aliases to the toolchain binaries
Now, here's the output of valgrind when I try to run the leak program under it:
-------------------------8<------------------------------------
$valgrind -v leak
valgrind -v leak
==15975== Memcheck, a memory error detector
==15975== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15975== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==15975== Command: leak
==15975==
--15975-- Valgrind options:
--15975-- -v
--15975-- Contents of /proc/version:
--15975-- Linux version 2.6.12.3-PQ2 (r...@rambo) (gcc version 4.0.2
20060628 (Wasabi)) #1 Fri Apr 23 14:07:04 WEST 2010
--15975-- Arch and hwcaps: PPC32, ppc32-int-flt-GX
--15975-- Page sizes: currently 4096, max supported 65536
--15975-- Valgrind library directory: /valgrind/lib/valgrind
--15975-- Reading syms from /lib/ld-2.3.6.so (0x4000000)
--15975-- Reading syms from /tmp/leak (0x10000000)
--15975-- WARNING: Serious error when reading debug info
--15975-- When reading debug info from /tmp/leak:
--15975-- Can't make sense of .sdata section mapping
--15975-- Reading syms from
/valgrind/lib/valgrind/memcheck-ppc32-linux (0x38000000)
--15975-- object doesn't have a dynamic symbol table
--15975-- Reading suppressions file: /valgrind/lib/valgrind/default.supp
--15975-- REDIR: 0x4012870 (strlen) redirected to 0x38048448
(vgPlain_ppc32_linux_REDIR_FOR_strlen)
--15975-- REDIR: 0x4012780 (strcmp) redirected to 0x38048470
(vgPlain_ppc32_linux_REDIR_FOR_strcmp)
--15975-- REDIR: 0x40126a8 (index) redirected to 0x380484e4
(vgPlain_ppc32_linux_REDIR_FOR_strchr)
--15975-- Reading syms from
/valgrind/lib/valgrind/vgpreload_core-ppc32-linux.so (0xffde000)
--15975-- WARNING: Serious error when reading debug info
--15975-- When reading debug info from
/valgrind/lib/valgrind/vgpreload_core-ppc32-linux.so:
--15975-- Can't make sense of .sdata section mapping
--15975-- Reading syms from
/valgrind/lib/valgrind/vgpreload_memcheck-ppc32-linux.so (0xffb5000)
--15975-- WARNING: Serious error when reading debug info
--15975-- When reading debug info from
/valgrind/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--15975-- Can't make sense of .sdata section mapping
--15975-- Reading syms from /lib/libc-2.3.6.so (0xfe65000)
==15975==
==15975== HEAP SUMMARY:
==15975== in use at exit: 0 bytes in 0 blocks
==15975== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==15975==
==15975== All heap blocks were freed -- no leaks are possible
==15975==
==15975== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 5)
--15975--
--15975-- used_suppression: 2 Ubuntu-stripped-ld.so
--15975-- used_suppression: 1 glibc-2.3.x-on-SuSE-10.1-(PPC)-1
--15975-- used_suppression: 4 glibc-2.3.x-on-SuSE-10.0-(PPC)-1
==15975==
==15975== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 5)
----------------8<------------------------------
This is rather strange, as it is obvious that the program is
allocating memory and not freeing it on exit.
I did lot of searching on this issue but couldn't find anything useful.
This thread here:
http://www.mail-archive.com/[email protected]/msg01949.html
suggests adding -gdwarf-2 to the build of both valgrind and the
application to debug. This didn't change the behaviour at all.
I'm puzzled that valgrind complains on its own files, like
memcheck-ppc32-linux, saying that they don't contain a dynamic symbol
table.
Am I doing something wrong when compiling valgrind?
Version 3.4.0 compiled fine and worked without tricks. Unfortunately
when supervising a complex application, the application fails to start
a couple of times.
The same application runs find under valgrind 3.6.0 but memory
allocations are not being detected.
Any ideas on what's causing this?
Thanks in advance.
--to
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
