> Few dynamically loaded libraries were statically linked to few other
> libraries. After converting them to dynamic libraries, I am closer to
> detect memory problems. Also, I had to turn on -g and avoid stripping the
> executable to get an accurate detection
>
> However, this still dazzle
On 02/06/14 15:05, Vignesh wrote:
> However, this still dazzles me:
>
> I still get this warning while running valgrind:
> --8925-- Considering /system/lib/libc.so ..
> --8925-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --8925--object doesn't have a symbol table
>
> When I comp
Thank you for your clues.
Few dynamically loaded libraries were statically linked to few other libraries.
After converting them to dynamic libraries, I am closer to detect memory
problems. Also, I had to turn on -g and avoid stripping the executable to get
an accurate detection
However, th
> --16527-- Considering /system/lib/libc.so ..
> --16527-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --16527--object doesn't have a symbol table
The checksums mismatch, so memcheck ignores the symbols [if there are any.]
Therefore 'malloc' and 'free' cannot be found.
Most often
Hi,
I am still facing troubles getting a valgrind report on an android phone
(armv7-a-neon) after changing my executable to be a dynamically loaded
executable.
I am not very sure, if I understand the output of the following.
..
..--16527:1:main Starting the address space manager
Keep us updated pls
El 26/05/2014 11:59, "Vignesh" escribió:
> Thank you. My executable was a statically linked one.
>
> Will change it to a dynamic executable and hope to have no issues.
>
> -Vignesh
>
>
> On Saturday, 24 May 2014, 23:24, Philippe Waroquiers <
> [email protected]>
Thank you. My executable was a statically linked one.
Will change it to a dynamic executable and hope to have no issues.
-Vignesh
On Saturday, 24 May 2014, 23:24, Philippe Waroquiers
wrote:
On Sat, 2014-05-24 at 12:21 +0100, Vignesh wrote:
>
> ==268== HEAP SUMMARY:
> ==268== in
On Sat, 2014-05-24 at 12:21 +0100, Vignesh wrote:
>
> ==268== HEAP SUMMARY:
> ==268== in use at exit: 0 bytes in 0 blocks
> ==268== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
This seems to indicate that malloc interception is not working.
Try to run with -v -v -v -d -d -d -trac
Hi,
I am having troubles finding memory leaks and array over shoots with valgrind
on android.
I have a binary that intentionally leaks few bytes. When I run the binary in
valgrind environment on an android phone (adb shell), I see valgrind reporting
no errors.
Please help me understand if I
