|
You are completely right. It works.
Thank you!
Kind regards,
Jan
|
|
You need to mongoc_uri_destroy(uri); when you are finished with the uri.
In general, the rule of thumb is "everything that you get from _new() must be _destroyed():
xxx = ..._new();
...._destroy(xxx);
For complete client_pool example, see the docs: http://api.mongodb.org/c/current/mongoc_client_pool_t.html
|
|
Hello,
I have downloaded latest version of Valgrind source 3.10.1 and compiled in my system. It does not show segmentation faults any more. Thank you.
However there is still leak reported for mongoc_client_pool_new(). When using non-pooled version (mongoc_client_new(), commented out bellow) it is all fine, no leaks/errors are shown.
When I have debugged my application (not just this isolated piece of code) with valgrind I have received exactly the same leaks in bson_malloc0 -> calloc.
#include <mongoc.h>
|
|
int main (int argc, char *argv[])
|
{
|
mongoc_client_pool_t *client_pool;
|
mongoc_uri_t *uri;
|
|
//mongoc_client_t *client;
|
|
mongoc_init ();
|
uri = mongoc_uri_new("mongodb://localhost:27018/?replicaSet=esbvrirs0");
|
client_pool = mongoc_client_pool_new(uri);
|
|
//client = mongoc_client_new("mongodb://localhost:27018/?replicaSet=esbvrirs0");
|
}
|
|
[esb@czcholsint755 src]$ gcc ./test.c -ggdb -o test2 -lmongoc-1.0 -I/usr/local/include/libmongoc-1.0 -I/usr/local/include/libbson-1.0
|
[esb@czcholsint755 src]$ /usr/local/bin/valgrind --leak-check=yes ./test2
|
==32592== Memcheck, a memory error detector
|
==32592== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
|
==32592== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
|
==32592== Command: ./test2
|
==32592==
|
==32592==
|
==32592== HEAP SUMMARY:
|
==32592== in use at exit: 2,642 bytes in 11 blocks
|
==32592== total heap usage: 47 allocs, 36 frees, 2,958 bytes allocated
|
==32592==
|
==32592== 1,257 (640 direct, 617 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 11
|
==32592== at 0x4A05F6F: calloc (vg_replace_malloc.c:623)
|
==32592== by 0x4E5D816: bson_malloc0 (bson-memory.c:103)
|
==32592== by 0x4C3A214: mongoc_uri_new (mongoc-uri.c:797)
|
==32592== by 0x400601: main (test.c:13)
|
==32592==
|
==32592== LEAK SUMMARY:
|
==32592== definitely lost: 640 bytes in 1 blocks
|
==32592== indirectly lost: 617 bytes in 4 blocks
|
==32592== possibly lost: 0 bytes in 0 blocks
|
==32592== still reachable: 1,385 bytes in 6 blocks
|
==32592== suppressed: 0 bytes in 0 blocks
|
==32592== Reachable blocks (those to which a pointer was found) are not shown.
|
==32592== To see them, rerun with: --leak-check=full --show-leak-kinds=all
|
==32592==
|
==32592== For counts of detected and suppressed errors, rerun with: -v
|
==32592== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
|
Do you think this is issue in bson, valgrind, my code or where?
Can you also set this issue as reopened? I cannot do it myself.
Thank you
Kind regards,
Jan
|
(gdb) help strace
|
Set a static tracepoint at specified line, function or marker.
|
|
strace [LOCATION] [if CONDITION]
|
I'm not sure what you are trying to achieve by running strace there.
The program finished successfully. Its not returning a normal exit code because you aren't exiting the main() function correctly.
I would recommend installing the latest up2date valgrind on your platform and test it with a simple c application not using the driver.
As you can see, the application using the driver runs without problems under gdb and standalone.
When you run it under valgrind, valgrind complains about it not handling certain opcodes – which means an error in valgrind, not the driver.
This is though likely caused by an outdated valgrind version.
|
|
Hello Hannes,
Sorry for late response, I was on vacation.
Version of Valgrind used is: valgrind-3.6.0
I have also tried the same excercise in Ubuntu 14.04 with valgrind-3.10.0 with exactly the same results.
It runs with no errors without valgrind. The thing is I get memory problems in my application later which I wanted to resolve using valgrind. I have isoleted the problem step by step to the simple C program that I have attached earlier.
What platform do you use for builing so that it runs correctly for you? I will try to get there, too.
Here is my gdb session
[esb@czcholsint755 src]$ gcc ./test.c -ggdb -o test2 -lmongoc-1.0 -I/usr/local/include/libmongoc-1.0 -I/usr/local/include/libbson-1.0
|
[esb@czcholsint755 src]$ gdb ./test2
|
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
|
Copyright (C) 2010 Free Software Foundation, Inc.
|
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
|
This is free software: you are free to change and redistribute it.
|
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
|
and "show warranty" for details.
|
This GDB was configured as "x86_64-redhat-linux-gnu".
|
For bug reporting instructions, please see:
|
<http://www.gnu.org/software/gdb/bugs/>...
|
Reading symbols from /appl/INSTALL/ESBArchivingLogging/aggr/src/test2...done.
|
(gdb) run
|
Starting program: /appl/INSTALL/ESBArchivingLogging/aggr/src/test2
|
[Thread debugging using libthread_db enabled]
|
|
Program exited with code 0320.
|
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.9.x86_64
|
(gdb) bt
|
No stack.
|
(gdb) strace
|
Segmentation fault
|
If I run the program with empty main() it returns
Program exited with code 0140.
Thank you
Jan
|
|
I can't reproduce this, I suspect you may be running very old Valgrind (or a build not compatible with your platform), and everything should be working fine if you run without it.
I'm closing the ticket for now, but feel free to open it if you are still experiencing this and can answer the questions above.
|
|
Does it run without valgrind?
Can you run the code through gdb and if it crashes then post the backtrace?
Also, which valgrind version is this?
|
|
Hello,
sorry for confusion. The reason is I have tried both, pool first as this is what I need and then I tried to simplify to non-pool version. Still I think the code was right. Never the less I have recompiled the drivers as
|
Compilation
|
./configure --enable-static --enable-debug-symbols=full
|
make
|
sudo make install
|
I'm sure there is no clash with other driver's version.
I changed the code to reduce confusion, hopefully
|
test.c
|
#include <mongoc.h>
|
#include <stdio.h>
|
|
mongoc_client_pool_t *client_pool;
|
|
void mongodb_new()
|
{
|
mongoc_uri_t *uri;
|
|
mongoc_init ();
|
uri = mongoc_uri_new("mongodb://localhost:27018/?replicaSet=esbvrirs0");
|
client_pool = mongoc_client_pool_new(uri);
|
}
|
|
void mongodb_delete()
|
{
|
mongoc_client_pool_destroy(client_pool);
|
mongoc_cleanup();
|
}
|
|
int main (int argc, char *argv[])
|
{
|
mongodb_new();
|
// mongodb_delete();
|
}
|
Programm compiled as
|
Output
|
gcc ./test.c -o test2 -lmongoc-1.0 -I/usr/local/include/libmongoc-1.0 -I/usr/local/include/libbson-1.0
|
Ouput from
valgrind --leak-check=yes ./test
|
Output
|
--8640-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x8
|
==8640== Jump to the invalid address stated on the next line
|
==8640== at 0xFFFFFFFFFF600800: ???
|
==8640== by 0x4006BA: mongodb_new (in /appl/INSTALL/ESBArchivingLogging/aggr/src/test)
|
==8640== by 0x4006F6: main (in /appl/INSTALL/ESBArchivingLogging/aggr/src/test)
|
==8640== Address 0xffffffffff600800 is not stack'd, malloc'd or (recently) free'd
|
==8640==
|
==8640==
|
==8640== Process terminating with default action of signal 11 (SIGSEGV): dumping core
|
==8640== Bad permissions for mapped region at address 0xFFFFFFFFFF600800
|
==8640== at 0xFFFFFFFFFF600800: ???
|
==8640== by 0x4006BA: mongodb_new (in /appl/INSTALL/ESBArchivingLogging/aggr/src/test)
|
==8640== by 0x4006F6: main (in /appl/INSTALL/ESBArchivingLogging/aggr/src/test)
|
==8640==
|
==8640== HEAP SUMMARY:
|
==8640== in use at exit: 2,642 bytes in 11 blocks
|
==8640== total heap usage: 47 allocs, 36 frees, 2,958 bytes allocated
|
==8640==
|
==8640== 1,385 (128 direct, 1,257 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 11
|
==8640== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
|
==8640== by 0x4E59816: bson_malloc0 (bson-memory.c:103)
|
==8640== by 0x4C23A60: mongoc_client_pool_new (mongoc-client-pool.c:77)
|
==8640== by 0x4006BA: mongodb_new (in /appl/INSTALL/ESBArchivingLogging/aggr/src/test)
|
==8640== by 0x4006F6: main (in /appl/INSTALL/ESBArchivingLogging/aggr/src/test)
|
==8640==
|
==8640== LEAK SUMMARY:
|
==8640== definitely lost: 128 bytes in 1 blocks
|
==8640== indirectly lost: 1,257 bytes in 5 blocks
|
==8640== possibly lost: 0 bytes in 0 blocks
|
==8640== still reachable: 1,257 bytes in 5 blocks
|
==8640== suppressed: 0 bytes in 0 blocks
|
==8640== Reachable blocks (those to which a pointer was found) are not shown.
|
==8640== To see them, rerun with: --leak-check=full --show-reachable=yes
|
==8640==
|
==8640== For counts of detected and suppressed errors, rerun with: -v
|
==8640== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
|
Segmentation fault
|
There is the segfault again.
What else I can check or try?
Thank you
Regards
Jan
|
|
I'm highly confused.
The mongodb_delete() function is incorrect – you aren't using mongoc_client_pools, but since that call is commented out I've got no idea.
(see http://api.mongodb.org/c/current/mongoc_client_pool_t.html for more info about client pooling).
How did you compile and install mongoc?
Could you recompile with '--enable-debug-symbols=full' and run it again?
Your example works fine locally, and I can't think of anything that would be causing this off-the-top-of-my-head..
|
Generated at Wed Feb 07 21:10:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.