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
