Also, although your main application clearly has debug information, your target 
file system's libraries may not.  Make sure that you have debuginfo files in 
/usr/lib/.debug (default) or /usr/lib/debug.  I'm not sure how valgrind 
intercepts the malloc/free calls, but I assume that valgrind will have a 
terrible time backtracing without dwarf info, at least on some flavors of arm.

Dave
--------------------------------------------
On Thu, 5/7/15, David Lerner <david.lerne...@sbcglobal.net> wrote:

 Subject: Re: Valgrind, Yocto tunning on arm flags
 To: david.and...@netmodule.com
 Cc: valgrind-users@lists.sourceforge.net
 Date: Thursday, May 7, 2015, 5:42 PM
 
 Hi David,
 
 The patch that you site should not be related with the root
 cause of your backtrace failure.  
 
 The patch can not impact the run-time binaries since it only
 removes building some valgrind tests that wouldn't compile
 in the yocto cross-compilation environment, as well as some
 test specific CFLAGs.  These tests are built when the
 yocto PTEST framework is enabled, but typically not
 installed into even a developer's file system image.
 
 Dave Lerner
 
 
 > -----Original Message-----
 > From: David Andrey [mailto:david.and...@netmodule.com]
 > Sent: Wednesday, May 06, 2015 3:24 AM
 > To: valgrind-users@lists.sourceforge.net
 > Cc: Lerner, Dave
 > Subject: Valgrind, Yocto tunning on arm flags
 >
 > Hi everybody,
 >
 > I'm new to Valgrind and have some questions about
 architecture flags. Running the
 > Valgrind memchecker provided by Yocto on an ARMv7
 CortexA9 (iMX6) I see the stack trace,
 > except for memory leaks. So I decide to build Valgrind
 by my own, and everything was
 > right.
 >
 > Actually, I don't have enough knowledge to understand
 all the tricks about compiler
 > flags for ARM, but I suppose something is conflicting
 with this additional Yocto patch
 > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-
 >
 devtools/valgrind/valgrind/remove-arm-variant-specific.patch
 >
 >
 > Can anyone check if this patch is ok for Valgrind or
 give me some hints ?
 >
 > Here is my test, just for the log
 >
 > Source code
 >
 >   #include <stdlib.h>
 >
 >   void f(void)
 >   {
 >      int* x = malloc(10 * sizeof(int));
 >      x[10] = 0;     
   // problem 1: heap block overrun
 >   }         
           // problem 2: memory leak
 -- x not freed
 >
 >   int main(void)
 >   {
 >      f();
 >      return 0;
 >   }
 >
 > Running Yocto provided Valgrind
 >
 >   valgrind --leak-check=full
 --keep-stacktraces=alloc-and-free --num-callers=20 --track-
 > origins=yes --leak-resolution=high ./memcheck-example
 >
 > leads to
 >
 >         ==3510==
 Memcheck, a memory error detector
 >         ==3510==
 Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
 al.
 >         ==3510== Using
 Valgrind-3.10.1 and LibVEX; rerun with -h for copyright
 info
 >         ==3510== Command:
 ./memcheck-example
 >         ==3510==
 >         ==3510== Invalid
 write of size 4
 >         ==3510== 
   at 0x8454: f (memcheck-example.c:6)
 >         ==3510== 
   by 0x846B: main (memcheck-example.c:11)
 >         ==3510== 
 Address 0x497b050 is 0 bytes after a block of size 40
 alloc'd
 >         ==3510== 
   at 0x48377C4: malloc (in
 /usr/lib/valgrind/vgpreload_memcheck-arm-
 > linux.so)
 >         ==3510==
 >         ==3510==
 >         ==3510== HEAP
 SUMMARY:
 >         ==3510== 
    in use at exit: 40 bytes in 1 blocks
 >     
    ==3510==   total heap
 usage: 1 allocs, 0 frees, 40 bytes allocated
 >         ==3510==
 >         ==3510== 40 bytes
 in 1 blocks are definitely lost in loss record 1 of 1
 >         ==3510== 
   at 0x48377C4: malloc (in
 /usr/lib/valgrind/vgpreload_memcheck-arm-
 > linux.so)
 >         ==3510==
 >         ==3510== LEAK
 SUMMARY:
 >         ==3510== 
   definitely lost: 40 bytes in 1 blocks
 >         ==3510== 
   indirectly lost: 0 bytes in 0 blocks
 >         ==3510== 
     possibly lost: 0 bytes in 0 blocks
 >         ==3510== 
   still reachable: 0 bytes in 0 blocks
 >         ==3510== 
        suppressed: 0 bytes in 0
 blocks
 >
 > so without stack trace for mem leak
 >
 > Regards
 > David
      
 

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to