My Mongodb-c-driver program working well, without errors at the compiling and run time, but when I check the program with Valgrind I have memory leak.
==30532== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30532== by 0x506BCA5: bson_malloc0 (in /usr/local/lib/libbson-1.0.so.0.0.0)
==30532== by 0x4E3B0CB: mongoc_client_new (in /usr/local/lib/libmongoc-1.0.so.0.0.0)
==30532== by 0x4009BA: main (ranker.c:28)
==30532== LEAK SUMMARY:
==30532== definitely lost: 6,656 bytes in 1 blocks
==30532== indirectly lost: 2,598 bytes in 11 blocks
==30532== possibly lost: 0 bytes in 0 blocks
==30532== still reachable: 0 bytes in 0 blocks
==30532== suppressed: 0 bytes in 0 blocks
==30532== For counts of detected and suppressed errors, rerun with: -v
==30532== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
The Valgrind notes the line with:
client = mongoc_client_new ("mongodb://localhost:27017/");
In the last lines in program I have:
mongoc_client_destroy (client);
What is that and what can I do in order to avoid LEAK SUMMARY?
Edit: I still have some issues during work with MongoDB, is there anyone out there who knows how can I solve this problem?
Have you called the mongoc_cleanup() routine at the end of main()? The MongoDB C driver has some internal state that is initialized during startup (especially for SSL). It needs to be released manually by calling the cleanup function at the end of your program.
Here is an example: https://github.com/mongodb/mongo-c-driver/blob/b2b5c6e8ebdcbf8593292ae8efcb91b94aa23995/examples/example-client.c#L72
Hope that helps,
-- Christian
Related
I recognize that many do not consider "still reachable" memory leaks to be true memory leaks. However, I'm trying to get Valgrind to report errors whenever an error is "still reachable". To be more specific, this is my current output:
HEAP SUMMARY:
in use at exit: 23,221,680 bytes in 25 blocks
total heap usage: 27 allocs, 2 frees, 23,222,816 bytes allocated
Searching for pointers to 25 not-freed blocks
Checked 49,347,544 bytes
672 bytes in 24 blocks are still reachable in loss record 1 of 2
at 0x4C29792: malloc (** DETAILS OMITTED **)
by 0x2011F54: (** DETAILS OMITTED **)
by 0x405C75: main (** DETAILS OMITTED **)
23,221,008 bytes in 1 blocks are still reachable in loss record 2 of 2
at 0x4C29792: malloc (** DETAILS OMITTED **)
by 0x2011F54: (** DETAILS OMITTED **)
by 0x21B34CC: (** DETAILS OMITTED **)
by 0x20125DF: (** DETAILS OMITTED **)
by 0x406D14: main (** DETAILS OMITTED **)
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 23,221,680 bytes in 25 blocks
suppressed: 0 bytes in 0 blocks
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
The two suppressed errors are coming from "still reachable" errors. I would like these to be considered proper errors so that the program returns an error code.
The two suppressed errors are coming from "still reachable" errors.
Almost surely not. The results of the leak check performed at program exit are largely separate from the analysis of erroneous memory accesses performed as the program runs. You can test with a dummy program such as this one that still-reachable memory does not produce a suppressed error:
#include <stdlib.h>
int main(void) {
void *p = malloc(8);
return (int) p;
}
I get
==22685== LEAK SUMMARY:
==22685== definitely lost: 0 bytes in 0 blocks
==22685== indirectly lost: 0 bytes in 0 blocks
==22685== possibly lost: 0 bytes in 0 blocks
==22685== still reachable: 8 bytes in 1 blocks
==22685== suppressed: 0 bytes in 0 blocks
==22685==
==22685== For counts of detected and suppressed errors, rerun with: -v
==22685== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Note well that 8 bytes are reported still reachable, and there are zero suppressed (or unsuppressed) errors.
I would like these to be considered proper errors so that the program returns an error code.
The point of suppressions is to ignore known, believed-harmless erroneous behavior, typically of system libraries. Although you can write your own suppression files, the suppressions you get by default arise from components out of your control.
It's an altogether different thing to exit with an error code in the event of various kinds of leak. You wrote in comments that you are running your valgrind test like so:
valgrind --leak-check=full --show-reachable=yes --show-leak-kinds=all --error-exitcode=1 \
--track-origins=yes --log-file=LOG_FILE_NAME -v EXECUTABLE_NAME
Notably missing from the options you are providing is --errors-for-leak-kinds, which is separate from --show-leak-kinds, and defaults to definite,possible. The combination --error-exitcode=1 --errors-for-leak-kinds=all should cause valgrind to count (and report) all classes of leaks as errors, and therefore to exit with status 1 in the event that it detects any memory still allocated when the program exits.
Is there a way to let valgrind to report "where" a "definitely lost" happens?
What I want is not "where it's allocated", but "where that poor piece of memory got leaked".
For example, this piece of code has a "definitely lost" leak when f() returns:
#include <stdlib.h>
void f () {
void *ptr = malloc(42);
}
int main () {
f();
return 0;
}
But valgrind only reports the origin of allocation:
==9772== HEAP SUMMARY:
==9772== in use at exit: 42 bytes in 1 blocks
==9772== total heap usage: 1 allocs, 0 frees, 42 bytes allocated
==9772==
==9772== 42 bytes in 1 blocks are definitely lost in loss record 1 of 1
==9772== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9772== by 0x40053E: f (test.c:4)
==9772== by 0x400552: main (test.c:8)
==9772==
==9772== LEAK SUMMARY:
==9772== definitely lost: 42 bytes in 1 blocks
==9772== indirectly lost: 0 bytes in 0 blocks
==9772== possibly lost: 0 bytes in 0 blocks
==9772== still reachable: 0 bytes in 0 blocks
==9772== suppressed: 0 bytes in 0 blocks
==9772==
==9772== For counts of detected and suppressed errors, rerun with: -v
==9772== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
I'm using --leak-check=full and --track-origins=yes.
What I want is not "where it's allocated", but "where that poor piece
of memory got leaked".
No, Valgrind only reports where the memory was allocated, but not when how or why it was leaked. This behavior is documented in Memcheck manual:
If --leak-check=full is specified, Memcheck will give details for each
definitely lost or possibly lost block, including where it was
allocated. (Actually, it merges results for all blocks that have the
same leak kind and sufficiently similar stack traces into a single
"loss record". The --leak-resolution lets you control the meaning of
"sufficiently similar".) It cannot tell you when or how or why the
pointer to a leaked block was lost; you have to work that out for
yourself.
Also --track-origins has nothing to do with memory leaks. It is used for tracking the origin of uninitialised values.
I have a C code OpenGL program that compiles and runs fine on my ubuntu machine. But when I compile and run it on another linux it causes a segmentation fault. I've used valgrind to see where the problem could be and here is a small portion of the output:
==21294== LEAK SUMMARY:
==21294== definitely lost: 72 bytes in 1 blocks
==21294== indirectly lost: 0 bytes in 0 blocks
==21294== possibly lost: 0 bytes in 0 blocks
==21294== still reachable: 191,932 bytes in 1,397 blocks
==21294== suppressed: 0 bytes in 0 blocks
==21294==
==21294== ERROR SUMMARY: 8 errors from 3 contexts (suppressed: 0 from 0)
==21294==
==21294== 1 errors in context 1 of 3:
==21294== Syscall param ioctl(generic) points to uninitialised byte(s)
==21294== at 0x5936F07: ioctl (syscall-template.S:84)
==21294== by 0x7C0E0E7: drmIoctl (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==21294== by 0x7C10DDE: drmCommandWriteRead (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==21294== by 0xABF2DA0: nouveau_object_mthd (in /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0)
==21294== by 0xABF3535: nouveau_device_new (in /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0)
==21294== by 0xA0B9690: nouveau_drm_screen_create (in /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so)
==21294== by 0x9C7FD15: ??? (in /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so)
==21294== by 0x9F6C59B: ??? (in /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so)
==21294== by 0x9F67BD2: ??? (in /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so)
==21294== by 0x4E80AA2: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
==21294== by 0x4E589C3: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
==21294== by 0x4E53F00: glXQueryVersion (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
The full output file from valgrind is 15614 lines long.
I'm still learning it but I could use assistance on reading what I'm looking at and how I can correct my code. Also this is my first post on this site, so any info for this question and posting in general would be appreciated.
Segmentation fault has nothing to do with memory leaks. To fix segmentation fault you should read and fix errors reported by Valgrind, not memory leaks. According to output there are 8 errors found by Valgrind:
==21294== ERROR SUMMARY: 8 errors from 3 contexts (suppressed: 0 from 0)
See the difference between Valgrind errors and memory leaks here:
Error summary in Valgrind output?
I was just testing out some c code I was writing and I found that I had a lot of memory leaks, so I wanted to see where they were coming from. All the code I had was:
int main() {
return 0;
}
Just a simple main that did nothing and I had all these memory leaks:
==38882== HEAP SUMMARY:
==38882== in use at exit: 58,678 bytes in 363 blocks
==38882== total heap usage: 514 allocs, 151 frees, 62,544 bytes allocated
==38882==
==38882== LEAK SUMMARY:
==38882== definitely lost: 8,624 bytes in 14 blocks
==38882== indirectly lost: 1,168 bytes in 5 blocks
==38882== possibly lost: 4,925 bytes in 68 blocks
==38882== still reachable: 43,961 bytes in 276 blocks
==38882== suppressed: 0 bytes in 0 blocks
==38882== Rerun with --leak-check=full to see details of leaked memory
==38882==
==38882== For counts of detected and suppressed errors, rerun with: -v
==38882== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
When I run this code on my university's computers I have no memory leaks. Is there something on my local machine that is causing this many memory leaks?
It is fine. Your program uses runtime library (i.e. libc or equivalent) and the library allocates some memory for own needs.
I get the same error on my Mac. It's either a valgrind problem or (more likely) a library problem on the Mac. I would suggest to use valgrind only on Linux.
I've used valgrind before and it has been very helpful. I recently setup a dev environment and starting using valgrind again. This time it finds NO lost memory! Even if I malloc some memory and then interrupt the program with CTRL-C, I get the dump below. Can someone explain what's going on?
Confused....
==2489== HEAP SUMMARY:
==2489== in use at exit: 314,145 bytes in 585 blocks
==2489== total heap usage: 1,410 allocs, 825 frees, 2,025,829 bytes allocated
==2489==
==2489== LEAK SUMMARY:
==2489== definitely lost: 0 bytes in 0 blocks
==2489== indirectly lost: 0 bytes in 0 blocks
==2489== possibly lost: 0 bytes in 0 blocks
==2489== still reachable: 314,145 bytes in 585 blocks
==2489== suppressed: 0 bytes in 0 blocks
==2489== Reachable blocks (those to which a pointer was found) are not shown.
==2489== To see them, rerun with: --leak-check=full --show-reachable=yes
==2489==
==2489== For counts of detected and suppressed errors, rerun with: -v
==2489== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
If there is still a pointer to the malloced memory, it's not a leak. It's showing up as still reachable in the summary.
Memory that is not freeed is not necessarily leaked if it's still live, that is, there's still a pointer to it somewhere (globally, from the stack, or from registers.)