By default valgrind is not selectable in menuconfig for IMX6 platform when crosscompiling for Openwrt, but this platform is based on ARM Cortex A9 core which is implementing ARMv7 architecture. This architecture is supported by valgrind, so I made little changes in Makefile of valgrind package to make the package selectable from menuconfig and compilable.
I'm using GCC-5.3 and uClibc-0.9.33.2 (can't proceed to musl for now because it is very expensive).
The problem is that valgrind is not working properly even for /bin/true:
valgrind --leak-check=yes /bin/true
Output:
...
==24113== Invalid read of size 4
==24113== at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==24113== Address 0x7d99c9f4 is on thread 1's stack
==24113== 20 bytes below stack pointer
...
==24113== For counts of detected and suppressed errors, rerun with: -v
==24113== ERROR SUMMARY: 64 errors from 4 contexts (suppressed: 0 from 0)
As a workaround --ignore-range-below=44-13 valgrind parameter could be used.
As John Reiser said:
Using --ignore-range-below-sp does reduce the noise, but has the
danger of ignoring actual errors for references in that range.
Full description of this issue can be found at Valgrind-users mailing list under the topic:
[Valgrind-users] Valgrind not working properly on imx6 platform
Related
Using Valgrind to find if there is no leaks. I found these two commands online but what is the different? Is there a different Valgrind command other than these two that is better/correct?
valgrind --leak-check=yes ./program
Or
valgrind --leak-check=full -v ./program
man valgrind
-v, --verbose
Be more verbose. Gives extra information on various aspects of your program, such as: the shared objects loaded, the suppressions used, the progress of the instrumentation and execution engines, and warnings about
unusual behaviour. Repeating the option increases the verbosity level.
--leak-check= [default: summary]
When enabled, search for memory leaks when the client program finishes. If set to summary, it says how many leaks occurred. If set to full or yes, each individual leak will be shown in detail and/or counted as an error,
as specified by the options --show-leak-kinds and --errors-for-leak-kinds.
for example
==26460== 2 bytes in 1 blocks are still reachable in loss record 2 of 105
==26460== at 0x4C28BE3: malloc (vg_replace_malloc.c:299)
==26460== by 0x580D889: strdup (in /usr/lib64/libc-2.17.so)
==26460== by 0x4F50AF: init (init.c:468)
==26460== by 0x406D75: main (main.c:825)
I want to not check init.c:468: mode = strdup, i'm sure this only malloc once, and will last whole process life.
Is it possible to make valgrind not check this line?
As I said in my comment: I recommend not to.
But Valgrind does have a feature to suppress warnings.
The most convenient way of suppressing a specific message is supported by the feature dedicated to exactly that purpose:
--gen-suppressions=yes
Which apparently will ouptput the precise suppression syntax for each/any generated message.
See 5.1 in the FAQ:
http://valgrind.org/docs/manual/faq.html#faq.writesupp
(I love their style:
"F:Can you write ... for me?" and I expected a totally adequate
"A:No." But they actually answer
"A: Yes ...". Beyond cool.)
You should fix the leaks; it is far better to do so.
You can't stop Valgrind checking for the leaks, but you can stop it reporting them by suppressing the leaks.
Use:
valgrind --gen-suppressions=yes --leak-check=all -- tested-program …
You can then save the suppressions in a file, say tp.suppressions, and subsequently you use:
valgrind --suppressions=tp.suppressions -- tested-program …
If you work on a Mac like I do, and work with bleeding edge systems, you'll often find it necessary to suppress leaks from the system startup code — memory that's allocated before main() is called and which you cannot therefore control.
OTOH, it is routine that after the new release of macOS, it takes a while to get Valgrind running again. I upgraded to macOS High Sierra 10.13; Valgrind has stopped working again because the kernel isn't recognized.
I'm using Valgrind version 3.8.0 on OS X 10.8.1, Mountain Lion. Regarding compatibility with 10.8.1, Valgrind's site says (italics mine):
Valgrind 3.8.0 works on {x86,amd64}-darwin (Mac OS X 10.6 and 10.7, with limited support for 10.8).
I know, then, that there is only "limited support" for 10.8.1. Nonetheless, this bug report says (italics mine):
This (the latest 3.8.0 release) makes Valgrind
compile and able to run small programs on OSX 10.8. Be warned however
that it still asserts with bigger apps, and 32 bit programs are not
checked properly at all (most errors are missed by Memcheck).
Ok, that's fine. So Valgrind should work, if temperamentally, on 10.8.1. So now my question:
I was able to get Valgrind to compile on 10.8.1 with little trouble, but I saw some weird results when I ran it on a couple small C programs. To try and reduce the possible causes of the issue, I eventually wrote the following "program":
int main () {
return 0;
}
Not very exciting, and little room for bugs, I'd say. Then, I compiled and ran it through Valgrind:
gcc testC.c
valgrind ./a.out
Here's my output:
==45417== Command: ./a.out
==45417==
==45417== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==45417== WARNING: Expect incorrect results, assertions and crashes.
==45417== WARNING: In particular, Memcheck on 32-bit programs will fail to
==45417== WARNING: detect any errors associated with heap-allocated data.
==45417==
--45417-- ./a.out:
--45417-- dSYM directory is missing; consider using --dsymutil=yes
==45417==
==45417== HEAP SUMMARY:
==45417== in use at exit: 58,576 bytes in 363 blocks
==45417== total heap usage: 514 allocs, 151 frees, 62,442 bytes allocated
==45417==
==45417== LEAK SUMMARY:
==45417== definitely lost: 8,624 bytes in 14 blocks
==45417== indirectly lost: 1,168 bytes in 5 blocks
==45417== possibly lost: 4,925 bytes in 68 blocks
==45417== still reachable: 43,859 bytes in 276 blocks
==45417== suppressed: 0 bytes in 0 blocks
==45417== Rerun with --leak-check=full to see details of leaked memory
==45417==
==45417== For counts of detected and suppressed errors, rerun with: -v
==45417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I know that Valgrind is not ready for prime-time on 10.8.1. Nonetheless, I would love to be able to use it here – I only need to use it on small programs, and nothing is mission-critical about the results being spot-on. But clearly, it is reporting a ton of leaks in a program that seems very unlikely to be leaking. Thus:
What should I do to fix this?
Other info:
Adding an intentionally leaked integer does increment the "definitely lost" count by the appropriate 4 bytes.
Similarly, intentionally leaking a call to malloc by not freeing the memory does increment the heap alloc count appropriately.
Compiling with the -g flag and then running to Valgrind (to address the dSYM directory is missing error) does cause that error to disappear, but does not change the issue of tons of memory leaks being reported.
It tells you right there:
Expect incorrect results, assertions and crashes.
If you still want to run it, print detailed information about spurious leaks (--leak-check=full) and use it to suppress messages about them.
Valgrind trunk seems to have improved to the point where it is usable now. I haven't see it crash yet, but do have lots of false positives, which can be dealt with using a suppression file.
Right now, my suppression file looks like this:
# OS X 10.8 isn't supported, has a bunch of 'leaks' in the loader
{
osx_1080_loader_false_positive_1
Memcheck:Leak
...
fun:_ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
...
}
{
osx_1080_loader_false_positive_2
Memcheck:Leak
...
fun:_ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
...
}
{
osx_1080_loader_false_positive_3
Memcheck:Leak
...
fun:map_images_nolock
...
}
{
osx_1080_loader_false_positive_4
Memcheck:Leak
...
fun:_objc_fetch_pthread_data
fun:_ZL27_fetchInitializingClassLista
fun:_class_initialize
fun:_class_initialize
fun:_class_initialize
fun:_class_initialize
fun:prepareForMethodLookup
fun:lookUpMethod
fun:objc_msgSend
fun:_libxpc_initializer
fun:libSystem_initializer
}
I am also running valgrind from macports on mac osx 10.8. It runs without crashing but does produce some crazy results like the ones in this stackoverflow post, Confusing output from Valgrind shows indirectly lost memory leaks but no definitely lost or possibly lost.
I am doing some tests with Libgcrypt and when I use valgrind to check the memory usage there is 3,200 bytes in use at exit.
I have tried to use
valgrind --leak-check=full --track-origins=yes --show-reachable=yes ./my_program
But valgrind valgrind only complains about this line from my code:
version = gcry_check_version("1.5.0");
and valgrind about internal functions of Libgcrypt.
My test code is here: http://www.tiago.eti.br/storage/post2.c
And I am using Libgcrypt 1.5.0 from Debian sid repository
It is a bug of Libgcrypt or am I doing anything wrong?
Not all libraries are perfectly careful to clean up all their resources. As long as some "permanent" allocations happen only once and are in use until the end of the program (for example for a version string), it is entirely possible that the library just never bothers to deallocate this.
Thus is the unfortunate reality of dealing with third-party libraries, and if it bothers you, you should make a suppression file for Valgrind with --gen-suppressions=all.
Bear in mind that "still reachable" memory is just "laziness", and not really a leak, since you never actually lost the allocation. A leak should be considered a true programming error, while still reachable, un-deallocated memory may or may not be a forgivable shortcut.
I'm developing a library using a number of glib datastructures (GHashTable, GSList etc.). I've been checking my code frequently for memory leaks using valgrind. Most of the issues valgrind points out are quite easy to fix, however there's a few that I can't figure out.
All of these are reported as 'possibly lost'.
At the top of the valgrind stacktrace, I always find the same 4 libraries:
==29997== 1,512 bytes in 3 blocks are possibly lost in loss record 24 of 25
==29997== at 0x4004B11: memalign (vg_replace_malloc.c:532)
==29997== by 0x4004B6B: posix_memalign (vg_replace_malloc.c:660)
==29997== by 0x5E9AC4: ??? (in /lib/libglib-2.0.so.0.1200.3)
==29997== by 0x5EA4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)
Further down in the call stack, there is always a call to a glib function, such as g_key_file_new(), g_slist_prepend(), g_strsplit(), g_key_file_load_from_file(), g_file_get_contents().
My questions are:
Has anyone come across this and found a way around it?
Or is this something I can disregard? Is it due to glib using memory pools, as suggested here?
I am using
valgrind-3.5.0
glib-2.12.3
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
CentOS release 5.5 (Final)
GLib has a few features that confuse Valgrind.
One is memory pools (g_slice in newer glib, "mem chunks" in older). These are specialized allocators used for small objects such as list nodes. You can use this to disable the slice allocator:
G_SLICE=always-malloc valgrind myprogram
A second issue is that sometimes GLib would avoid initializing new memory or keep dead pointers in freed slices/chunks. You can fix this with:
G_DEBUG=gc-friendly valgrind myprogram
So together of course:
G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogram
A third issue is that GLib has global variables that are simply never freed but considered permanent program state. For example registered GType are never unloaded, and a few others. This is not fixable, but valgrind should show these global allocations as reachable, rather than as lost.
glib-2.12 is quite old.
Try getting glib-2.24, compile and install it (with --prefix=/usr/local/glib-2.24 for example) then use it to compile your application.
If you still have this, try to read the glib manual again :)