Hi All
I wonder if anyone can help. I've been running some tests on a trivial
application running in Linux on an ARM Cortex-A9 based device. I see a
difference in the output between the Valgrind 3.10 release and the more recent
3.11 version. As you can see from the log snippets below you can see that in
3.11 the call stacks are no longer shown. Instead I see a reference to a
valgrind .so only: "(in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)"
The Linux kernel version and filesystem in each case is different, with a
different GCC version used to generate the application under test and Valgrind
itself. The application code itself is the same in both cases - I have changed
it to deliberately leak memory (although it seems to have some leaks
'naturally' as well).
I've checked through the 3.11 release notes and tried manually reverting some
of the changes to Memcheck e.g. by setting '--keep-stacktraces=alloc-then-free'
but nothing seems to work.
Does anyone have any ideas why I see different behaviour?
Thanks in advance
Simon Goda
Output from Valgrind 3.10 (running on kernel 3.14):
$ ssh -fX root@192.168.1.10 /usr/local/bin/valgrind --leak-check=full
/usr/local/bin/xgalaga -window
==1161== Memcheck, a memory error detector
==1161== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1161== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
...
==1161==
==1161== HEAP SUMMARY:
==1161== in use at exit: 118,679 bytes in 828 blocks
==1161== total heap usage: 15,411 allocs, 14,583 frees, 1,147,134 bytes
allocated
==1161==
==1161== 28 (12 direct, 16 indirect) bytes in 1 blocks are definitely lost in
loss record 30 of 121
==1161== at 0x480FD74: realloc (vg_replace_malloc.c:692)
==1161== by 0x4835BF7: xpmParseExtensions (parse.c:577)
==1161== by 0x48339AB: xpmParseDataAndCreate (create.c:2223)
==1161== by 0x482EDAB: XpmCreateImageFromData (CrIFrDat.c:65)
==1161== by 0x482F04F: XpmCreatePixmapFromData (CrPFrDat.c:59)
==1161== by 0x1A807: W_LoadImage (image.c:171)
==1161== by 0x10CBB: getImage (images.c:6898)
==1161== by 0x140EB: init_explosions (explosions.c:159)
==1161== by 0x10ABB: main (main.c:1367)
==1161==
==1161== 144 bytes in 6 blocks are definitely lost in loss record 74 of 121
==1161== at 0x480D420: malloc (vg_replace_malloc.c:296)
==1161== by 0x13EE7: new_explosion (explosions.c:98)
==1161== by 0xE797: do_torps (main.c:722)
==1161== by 0x10BBB: main (main.c:1410)
...
Output from Valgrind 3.11 (running on kernel 4.4.0):
$ ssh -fX root@192.168.1.10 valgrind --leak-check=full /usr/local/bin/xgalaga
-window
==1027== Memcheck, a memory error detector
==1027== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1027== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
...
==1027== HEAP SUMMARY:
==1027== in use at exit: 118,684 bytes in 831 blocks
==1027== total heap usage: 85,261 allocs, 84,430 frees, 2,710,892 bytes
allocated
==1027==
==1027== 28 (12 direct, 16 indirect) bytes in 1 blocks are definitely lost in
loss record 2 of 7
==1027== at 0x4847FE4: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==1027==
==1027== 352 (304 direct, 48 indirect) bytes in 14 blocks are definitely lost
in loss record 4 of 7
==1027== at 0x48457E4: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
...
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
