Re: [Valgrind-users] Valgrind, Yocto tunning on arm flags

[David L. <dav...@sb...>]

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:Dav...@ne...]
> Sent: Wednesday, May 06, 2015 3:24 AM
> To: val...@li...
> 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