I have run my code through valgrind with these results:
==4492== Memcheck, a memory error detector
==4492== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4492== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4492== Command: ./mem
==4492== Parent PID: 4455
==4492==
==4492==
==4492== HEAP SUMMARY:
==4492== in use at exit: 0 bytes in 0 blocks
==4492== total heap usage: 19,595,342 allocs, 19,595,342 frees, 27,194,270 bytes allocated
==4492==
==4492== All heap blocks were freed -- no leaks are possible
==4492==
==4492== For counts of detected and suppressed errors, rerun with: -v
==4492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
However, while the code is running, I see a small, steady increase in the memory used by the program. How sure can I be with that result?
I run valgrind using:
valgrind --track-origins=yes --leak-check=yes
--tool=memcheck --read-var-info=yes --log-file=error.txt`
and I compile the program using the -g and the -march=core2 tags.
You need to distinguish between memory leaks (memory that was allocated, but you lost all references to) and memory hogs (memory that was allocated, that you keep references to, but forgot to deallocate).
The later one can not be detected by valgrind, since valgrind doesn't know you did not want to use it anymore.
To get some statistics about your programs memory usage, you can use the massif tool of valgrind, which will show you in more detail where your memory gets allocated. This might be helpful in finding memory hogs.
A small increase in memory usage is not necessarily something to worry about - it may be that your program is ramping up and will peak at some point. Without knowing the logic of that application, it's hard to tell. However, it's adamant that all allocated blocks were freed and it's usually pretty good.
You may want to consider letting it run for longer, increasing the work it has to do somehow (again this depends on the application) to see if it ever peaks or continues to rise forever (or until it runs out of virtual memory, anyway).
I'd also look at those last two lines:
==4492== For counts of detected and suppressed errors, rerun with: -v
==4492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
You may want to run it with -v just to check what those suppressions were. They may be nothing but it doesn't hurt to look into it.
Do you see memory usage increasing with a tool like top? Depending on the behavior of your program, if you allocate and free memory continually you may introduce fragmentation that causes the address space to grow. If you let the process run long enough it may stabilize and stop growing.
valgrind can detect memory leaks, but not poor usage of memory. It's possible that a bug in your code is continually allocating memory for no apparent reason, and that defensive code is then cleaning it all up afterwards anyway.
That said, I wouldn't trust your mechanism for determining your process's memory usage, either. There's a lot that goes on behind the scenes: caching, for one.
I'd call this "inconclusive".
Related
I want to test my C++ code for memory leaks with Valgrind (memcheck) x86.
But the software gets cross-compiled and is running on ARM.
In order to do some automated testing I decided to emulate my ARM hardware via QEMU.
And I also decided to use the cpputest unit test ARM binaries to ensure a deterministic behaviour and search for memory leaks within the scope the unit test covers.
All in all, I have an ARM binary which should be emulated via QEMU user mode.
My call looks like that:
./valgrind --smc-check=all qemu-arm-static -L ... arm-ptest-binary
My C++ code looks like that. It has a memory leak of 20 byte and the valgrind call do not find this leak when using it with QEMU.
After I insert a memory allocation and no freeing mechanism I'd have expected an memory leak
int test_func ()
{
int *foo;
foo = new int [5];
printf("test_func called!\n");
return 1;
}
Valgrind output:
==19300== HEAP SUMMARY:
==19300== in use at exit: 1,103,129 bytes in 2,316 blocks
==19300== total heap usage: 4,259 allocs, 1,943 frees, 1,866,916 bytes allocated
==19300==
==19300== LEAK SUMMARY:
==19300== definitely lost: 0 bytes in 0 blocks
==19300== indirectly lost: 0 bytes in 0 blocks
==19300== possibly lost: 304 bytes in 1 blocks
==19300== still reachable: 1,102,825 bytes in 2,315 blocks
==19300== suppressed: 0 bytes in 0 blocks
[...]
When I run this program on ARM hardware the valgrind-arm finds the leak with the exact same binary.
Does anyone of you have an idea why Valgrind does not find the memory leak in combination with QEMU user mode?
Thanks in advance
You are running Valgrind on QEMU itself, which will cause valgrind to report memory leaks in QEMU's own code, but valgrind does not have sufficient visibility into what the guest program running under QEMU is doing to be able to report leaks in the guest. In particular, Valgrind works by intercepting calls to malloc, free, operator new, etc -- it will be doing this for the host QEMU process's (x86) allocation and free calls, but has no way to intercept the (arm) calls your guest process makes.
You might look at running an entire guest OS under QEMU's system emulation mode, and then running the Arm Valgrind inside that on your guest program.
I just as of yesterday installed Ubuntu(terminal) on my windows computer. In addition, when ahead and installed Valgrind, "sudo apt install Valgrind", to test everything out I went ahead and create a c++ hello world program. Then tested it with Valgrind. The Valgrind said I had about "72,704 bytes in 1 block". Further research, I performed suggested this was a bug of Valgrind with the c++ standard library functions, possible the iostream. My question is how do I go about fixing this bug. I can't ignore because if I am working on programs I need to able to accurately gauge where it's coming from. If anyone can provide a step by step solution for my problem in layman's term for the problem it would be invaluable.
here is my code and errors I get:
#include <iostream>
using std::cout; using std::endl;
int main() {
cout << "Hello World" << endl;
}
==195== Memcheck, a memory error detector
==195== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==195== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==195== Command: ./helloworld
==195==
Hello World
==195==
==195== HEAP SUMMARY:
==195== in use at exit: 72,704 bytes in 1 blocks
==195== total heap usage: 2 allocs, 1 frees, 76,800 bytes allocated
==195==
==195== LEAK SUMMARY:
==195== definitely lost: 0 bytes in 0 blocks
==195== indirectly lost: 0 bytes in 0 blocks
==195== possibly lost: 0 bytes in 0 blocks
==195== still reachable: 72,704 bytes in 1 blocks
==195== suppressed: 0 bytes in 0 blocks
==195== Rerun with --leak-check=full to see details of leaked memory
==195==
==195== For counts of detected and suppressed errors, rerun with: -v
==195== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
update :
Seems like I can sort deal with the false positive leaks by creating suppression files. However, I am not as tech savvy compared some people on here to know how to do that. How would I create suppression files on Valgrind (specifically for my situation)? Please explain it in LAYMAN's terms and please be as detailed as possible.
second update:
I have been semi-successful in suppressing the memory leaks but I would like to know if there is a more viable long term solution out there.
I would say that these are most likely genuine issues, but probably too minor for the libc/libstdc++ developers to fix.
You can generate suppressions in the Valgrind output by specifying --gen-suppressions=yes. This will generate output like this:
==28328== 56 bytes in 1 blocks are still reachable in loss record 1 of 7
==28328== at 0x4C290F1: malloc (vg_replace_malloc.c:298)
==28328== by 0x4111D8: xmalloc (xmalloc.c:43)
==28328== by 0x41120B: xmemdup (xmalloc.c:115)
==28328== by 0x40F899: clone_quoting_options (quotearg.c:102)
==28328== by 0x40742A: decode_switches (ls.c:1957)
==28328== by 0x40742A: main (ls.c:1280)
==28328==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
fun:xmalloc
fun:xmemdup
fun:clone_quoting_options
fun:decode_switches
fun:main
}
In the above, the section with the pid (==28328==) is the usual output. The section after it (delimited by braces) is the generated suppression. You can copy this block into a file, for instance my_suppressions, and then you can run valgrind and tell it to read the file --suppressions=my_suppressions.
If you are planning on maintaining your suppressions file for a long time, then it is best to put some meaningful (and unique) text in the place of 'insert_a_suppression_name_here'. This will help you monitor which suppressions are being used, since if you run valgrind in verbose mode (-v or --verbose) it will list all of the used suppressions. For instance
--30822-- used_suppression: 2 Example for SO my_suppressions:2 suppressed: 112 bytes in 2 blocks
--30822-- used_suppression: 4 U1004-ARM-_dl_relocate_object /remote/us01home48/pfloyd/tools/vg313/lib/valgrind/default.supp:1431
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
I'm trying to debug a C++ Qt5 program but I'm unable, most of times it crashes on quit (when launched from shell).
When it's launched from valgrind or from gdb/lldb it doesn't crash.
I already tried generating a coredump and then loading but the results is helpless, only one frame in bt.
The actual code is hosted on github.
Valgrind output:
$ valgrind --tool=memcheck ./build/qsubber
==27761== Memcheck, a memory error detector
==27761== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==27761== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==27761== Command: ./build/qsubber
==27761==
==27761== Conditional jump or move depends on uninitialised value(s)
==27761== at 0x15D790FA: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.28)
==27761== by 0x9733523: ??? (in /usr/lib/libgobject-2.0.so.0.4400.1)
==27761== by 0x974CF96: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.4400.1)
==27761== by 0x974DE39: g_signal_emit_by_name (in /usr/lib/libgobject-2.0.so.0.4400.1)
==27761== by 0x973AC2A: g_object_set_valist (in /usr/lib/libgobject-2.0.so.0.4400.1)
==27761== by 0x973B4BB: g_object_set (in /usr/lib/libgobject-2.0.so.0.4400.1)
==27761== by 0x636ECC5: ??? (in /usr/lib/libQt5Widgets.so.5.5.0)
==27761== by 0x62F264C: QStyleFactory::create(QString const&) (in /usr/lib/libQt5Widgets.so.5.5.0)
==27761== by 0x628B704: QApplication::style() (in /usr/lib/libQt5Widgets.so.5.5.0)
==27761== by 0x628BACC: QApplicationPrivate::initialize() (in /usr/lib/libQt5Widgets.so.5.5.0)
==27761== by 0x628BB1E: QApplicationPrivate::construct() (in /usr/lib/libQt5Widgets.so.5.5.0)
==27761== by 0x413DFC: main (main.cc:34)
==27761==
Token: bp5tqvuocvv993496ppnds1j91
Status: 200 OK
==27761==
==27761== HEAP SUMMARY:
==27761== in use at exit: 6,490,962 bytes in 30,293 blocks
==27761== total heap usage: 167,918 allocs, 137,625 frees, 19,981,839 bytes allocated
==27761==
==27761== LEAK SUMMARY:
==27761== definitely lost: 5,152 bytes in 32 blocks
==27761== indirectly lost: 21,255 bytes in 779 blocks
==27761== possibly lost: 3,977,133 bytes in 7,134 blocks
==27761== still reachable: 2,305,790 bytes in 21,486 blocks
==27761== suppressed: 0 bytes in 0 blocks
==27761== Rerun with --leak-check=full to see details of leaked memory
==27761==
==27761== For counts of detected and suppressed errors, rerun with: -v
==27761== Use --track-origins=yes to see where uninitialised values come from
==27761== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Update
I'm not asking to debug this code for me, I need help to debug in this scenario, I've searched a lot and found some SO question/answers but nothing helped me until now so created this question.
I can offer some general guidelines from experience which might help. Also, with luck, this answer may be of some help to others with this class of problems, and not specific to your code.
If the crash (when not under debugger) is repeatable, that's good. Start stubbing out major functional parts of the code, one function at a time. you don't care if this test code "works" or not, just if it crashes on exit or not.
If you are lucky, it will keep crashing after a few iterations of this, then suddenly, not crash on exit any more. Examine which ever block of code you just stubbed out out closely.
A segfault is usually either a pointer that wrote off the end of some buffer, or a place where some function puts X bytes on the stack, then pops Y bytes off the stack later on (happened to me once when changing prototypes from 32 to 64 bit types).
You are unlucky if the first bit of code you stub out makes the problem go away, but when you put it back, and try stubbing something else out, it still goes away. Then you are dealing with something elsewhere in the program messing up your memory, and stubbing out arbitrary code not directly associated with the problem moves things around to make the bug appear or disappear.
One last thing to check, compiler optimization flags. It's really unlikely, but I have hit honest to goodness compiler bugs in my career. Try compiling with no optimizations at all and see if it still crashes on exit. Try compiling with max optimizations too. See if the behavior changes.
If none of this helps, you are going to have to go line by line looking for memory allocations and free spots and look for a mismatch.
Final thought, memory allocated for an object with local scope inside a function, and returned to the calling program via reference could be invalid, and is maybe trying to be cleaned up on program exit.
Good luck.
I have the following C++ file, pwd01.cpp:
#include <pwd.h>
#include <iostream>
int main() {
passwd* pwd = getpwuid(getuid());
}
I compile this with the following command:
g++ pwd01.cpp -Wall -o pwd01
On Ubuntu 12.04.1 LTS / gcc version 4.6.3, valgrind reports a leak (see below). When I compile the same code with the same command on Mac OS 10.6.8 / gcc version 4.2.1, valgrind reports no leaks.
I am aware that I do not need to free passwd* ( should I free pointer returned by getpwuid() in Linux? ); so what am I missing?
valgrind ./pwd01
==10618== Memcheck, a memory error detector
==10618== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==10618== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==10618== Command: ./pwd01
==10618==
==10618==
==10618== HEAP SUMMARY:
==10618== in use at exit: 300 bytes in 11 blocks
==10618== total heap usage: 68 allocs, 57 frees, 10,130 bytes allocated
==10618==
==10618== LEAK SUMMARY:
==10618== definitely lost: 60 bytes in 1 blocks
==10618== indirectly lost: 240 bytes in 10 blocks
==10618== possibly lost: 0 bytes in 0 blocks
==10618== still reachable: 0 bytes in 0 blocks
==10618== suppressed: 0 bytes in 0 blocks
==10618== Rerun with --leak-check=full to see details of leaked memory
==10618==
==10618== For counts of detected and suppressed errors, rerun with: -v
==10618== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Does not seem to be a "real" leak, i.e., if called several times, the leak doesn't compound; probably it holds a static pointer to a memory area, if it is NULL (the first time) it allocates those 60 bytes, and then doesn't free them up.
The MacOS X version either uses a truly static area, or its valgrind has got better suppressors.
Just run the getpwuid a couple hundred times in a loop to ensure it really leaks only 60 bytes (and not 1200), just to be sure.
UPDATE
I have finally tracked the leak to several structures inside nssswitch.c and getXXent.c, of different sizes and persuasions. While the code seems to make many more allocations than really necessary, needing malloc locks, this shouldn't be usually appreciable performance-wise, and I for one surely do not intend to second-guess the maintainers of glibc!
It may not be getpwuid() itself that is causing that (false) positive. It could be any number of other things that the C library initializes at start up time, but then doesn't tear down at process termination (because the process is going away, along with all the mapped memory that belongs to it, some things don't really need to be destructed/unallocated). As another answer said, run some additional tests, especially as you build more code beyond the simple example you provided, and make sure the numbers are stable, and not directly attributable to your own code. There's not much you can do about the library code directly, except submit a bug report (I'm assuming you're not one of the C library developers, anyway).
I'm doing a little bit of memory profiling to my software and after running standard memory leak check with valgrind's following command
valgrind --tool=memcheck --leak-check=full ./path_to_program
I got following summary:
==12550== LEAK SUMMARY:
==12550== definitely lost: 597,170 bytes in 7 blocks
==12550== indirectly lost: 120 bytes in 10 blocks
==12550== possibly lost: 770,281 bytes in 1,455 blocks
==12550== still reachable: 181,189 bytes in 2,319 blocks
==12550== suppressed: 0 bytes in 0 blocks
==12550== Reachable blocks (those to which a pointer was found) are not shown.
==12550== To see them, rerun with: --leak-check=full --show-reachable=yes
==12550==
==12550== For counts of detected and suppressed errors, rerun with: -v
==12550== ERROR SUMMARY: 325 errors from 325 contexts (suppressed: 176 from 11)
It doesn't look quite good to me, so my question is
Why isn't my program exploding if it has all these leaks?
And also what is the difference between:
definitely lost
indirectly lost
possibly lost
still reachable
and how can I try to fix them?
I suggest visiting the Valgrind FAQ:
With Memcheck's memory leak detector, what's the difference between
"definitely lost", "indirectly lost", "possibly lost", "still
reachable", and "suppressed"?
The details are in the Memcheck section
of the user manual.
In short:
"definitely lost" means your program is leaking memory -- fix those
leaks!
"indirectly lost" means your program is leaking memory in a
pointer-based structure. (E.g. if the root node of a binary tree is
"definitely lost", all the children will be "indirectly lost".) If you
fix the "definitely lost" leaks, the "indirectly lost" leaks should go
away.
"possibly lost" means your program is leaking memory, unless you're
doing unusual things with pointers that could cause them to point into
the middle of an allocated block; see the user manual for some
possible causes. Use --show-possibly-lost=no if you don't want to see
these reports.
"still reachable" means your program is probably ok -- it didn't free
some memory it could have. This is quite common and often reasonable.
Don't use --show-reachable=yes if you don't want to see these reports.
"suppressed" means that a leak error has been suppressed. There are
some suppressions in the default suppression files. You can ignore
suppressed errors.