|
From: durga p. <dur...@gm...> - 2011-06-04 06:35:06
|
Hi All, I am trying to run valgrind on ArmV7-CA9. I cross compile the valgrind 3.6.1 for the target android platform. But I am facing an issue when I was running the valgrind on the target platform. I had a test application with a memory leak of 100 bytes.When I run the valgrind with the test application its not showing the memory leak and also its giving segmentation fault on the target. Here I pasted the output of the valgrind. *# valgrind --leak-check=full /opt/test* ==647== Memcheck, a memory error detector ==647== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==647== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==647== Command: /opt/test ==647== ==647== Invalid read of size 4 ==647== at 0x4004D48: _dl_get_ready_to_run (in /lib/ ld-uClibc-0.9.30-nptl.so <http://ld-uclibc-0.9.30-nptl.so/>) ==647== Address 0xbd6b9a54 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==647== ==647== Invalid read of size 4 ==647== at 0x487849C: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so<http://libuclibc-0.9.30-nptl.so/> ) ==647== Address 0xbd6b9c44 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==647== ==647== Invalid read of size 4 ==647== at 0x4878500: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so<http://libuclibc-0.9.30-nptl.so/> ) ==647== Address 0x4002e054 is not stack'd, malloc'd or (recently) free'd ==647== ==647== ==647== Process terminating with default action of signal 11 (SIGSEGV) ==647== Access not within mapped region at address 0x4002E054 ==647== at 0x4878500: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so<http://libuclibc-0.9.30-nptl.so/> ) ==647== If you believe this happened as a result of a stack ==647== overflow in your program's main thread (unlikely but ==647== possible), you can try to increase the size of the ==647== main thread stack using the --main-stacksize= flag. ==647== The main thread stack size used in this run was 8388608. ==647== ==647== HEAP SUMMARY: ==647== in use at exit: 16 bytes in 2 blocks ==647== total heap usage: 2 allocs, 0 frees, 16 bytes allocated ==647== ==647== 8 bytes in 1 blocks are possibly lost in loss record 1 of 2 ==647== at 0x481B4B4: malloc (vg_replace_malloc.c:236) ==647== by 0x4879BF7: emutls_alloc (emutls.c:101) ==647== by 0x4879C97: __emutls_get_address (emutls.c:131) ==647== by 0x4853CBB: _stdio_init (in /lib/libuClibc-0.9.30-nptl.so<http://libuclibc-0.9.30-nptl.so/> ) ==647== ==647== 8 bytes in 1 blocks are possibly lost in loss record 2 of 2 ==647== at 0x481B4B4: malloc (vg_replace_malloc.c:236) ==647== by 0x4879BF7: emutls_alloc (emutls.c:101) ==647== by 0x4879C97: __emutls_get_address (emutls.c:131) ==647== by 0x483EE6F: __h_errno_location (in /lib/ libuClibc-0.9.30-nptl.so <http://libuclibc-0.9.30-nptl.so/>) ==647== ==647== LEAK SUMMARY: ==647== definitely lost: 0 bytes in 0 blocks ==647== indirectly lost: 0 bytes in 0 blocks ==647== possibly lost: 16 bytes in 2 blocks ==647== still reachable: 0 bytes in 0 blocks ==647== suppressed: 0 bytes in 0 blocks ==647== ==647== For counts of detected and suppressed errors, rerun with: -v ==647== ERROR SUMMARY: 27 errors from 5 contexts (suppressed: 0 from 0) Segmentation fault Also I tried to run the *ls* command with valgrind on the target.I am getting the same error segmentation fault. I ran the following command. *# valgrind -d -d -v -v --trace-flags=10000000 ls -l* Here I paste the part of the output where the valgrind is failing. ==== SB 628 [tid 1] __sigjmp_save+44(0x488a0fc) SBs exec'd 112056 ==== ==== SB 629 [tid 1] __uClibc_main+556(0x48924e8) SBs exec'd 112057 ==== ==== SB 630 [tid 1] __uClibc_main+564(0x48924f0) SBs exec'd 112058 ==== ==== SB 631 [tid 1] __aeabi_read_tp(0x484e440) SBs exec'd 112059 ==== ==== SB 632 [tid 1] (0xffff0fe0) SBs exec'd 112060 ==== ==== SB 633 [tid 1] __uClibc_main+568(0x48924f4) SBs exec'd 112061 ==== ==1200== Invalid read of size 4 ==1200== at 0x4892500: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so) ==1200== Address 0x4001c054 is not stack'd, malloc'd or (recently) free'd ==1200== ==1200== ==1200== Process terminating with default action of signal 11 (SIGSEGV) ==1200== Access not within mapped region at address 0x4001C054 ==1200== at 0x4892500: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so) ==1200== If you believe this happened as a result of a stack ==1200== overflow in your program's main thread (unlikely but ==1200== possible), you can try to increase the size of the ==1200== main thread stack using the --main-stacksize= flag. Any help would be appreciated Thanks in Advance, Durga Prasad |
|
From: John R. <jr...@bi...> - 2011-06-04 13:48:55
|
On 06/03/2011 11:35 PM, durga prasad wrote: > I had a test application with a memory leak of 100 bytes.When I run the valgrind with the > test application its not showing the memory leak Post the source code. It can't be that big, and it might not have any actual leak. and also its giving segmentation fault on the target [_after_ this:] > ==647== Invalid read of size 4 > ==647== at 0x4004D48: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.30-nptl.so <http://ld-uclibc-0.9.30-nptl.so/>) > ==647== Address 0xbd6b9a54 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes A SIGSEGV is likely after a reading a pointer from the unprotected side of $sp. -- |
|
From: durga p. <dur...@gm...> - 2011-06-04 16:35:38
|
The source which of the test application which I am testing with the
valgrind is pasted below.
#include <stdio.h>
#include <stdlib.h>
int main()
{
char *p;
// Allocation #1 of 19 bytes
p = (char *) malloc(19);
// Allocation #2 of 12 bytes
p = (char *) malloc(12);
free(p);
// Allocation #3 of 16 bytes
p = (char *) malloc(16);
return 0;
}
Also I tried to run the valgind on the x86 machine with same test
application.I am getting the results properly.
On Sat, Jun 4, 2011 at 7:19 PM, John Reiser <jr...@bi...> wrote:
> On 06/03/2011 11:35 PM, durga prasad wrote:
> > I had a test application with a memory leak of 100 bytes.When I run the
> valgrind with the
> > test application its not showing the memory leak
>
> Post the source code. It can't be that big,
> and it might not have any actual leak.
>
> and also its giving segmentation fault on the target [_after_ this:]
> > ==647== Invalid read of size 4
> > ==647== at 0x4004D48: _dl_get_ready_to_run (in /lib/
> ld-uClibc-0.9.30-nptl.so <http://ld-uclibc-0.9.30-nptl.so/>)
> > ==647== Address 0xbd6b9a54 is just below the stack ptr. To suppress,
> use: --workaround-gcc296-bugs=yes
>
> A SIGSEGV is likely after a reading a pointer from the unprotected side of
> $sp.
>
> --
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
regards
prasad.....
|