[CDRIVER-1909] Improve mongoc_init and mongoc_cleanup docs Created: 08/Nov/16  Updated: 28/Jan/17  Resolved: 27/Jan/17

Status: Closed
Project: C Driver
Component/s: docs, libmongoc
Affects Version/s: 1.3.3
Fix Version/s: 1.6.0

Type: Improvement Priority: Major - P3
Reporter: andre maute Assignee: A. Jesse Jiryu Davis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Update: to close this ticket, ensure that it's documented that mongoc_cleanup should be called once, and no other C Driver functions, not even mongoc_init, can be called after. Also, add links between mongoc_init, mongoc_cleanup, and the index page. Right now mongoc_cleanup is isolated.

After a long debugging tour I learned
that calling mongoc_init() and mongoc_cleanup() multiple times is bad practice
which might result in segmentation faults.

I suggest hereby adding

assert(once==MONGOC_ONCE_INIT)

to the implemetnations of these two functions,
for indicating that there might be a problem.

Regards
Andre



 Comments   
Comment by Githook User [ 28/Jan/17 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: CDRIVER-1909 improve init / cleanup docs
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/5bda9c810ae42647a493bfb23388686cd3439cee

Comment by andre maute [ 17/Nov/16 ]

Hi Jesse,

yes I can confirm that.

The debugging process was quite frustrating,
because we had only one installation where our problem happend.
At the beginning of the debugging session there was no hint at all
that pointed us to our usage of the mongoc api.

Regards
Andre

Comment by A. Jesse Jiryu Davis [ 09/Nov/16 ]

Thanks Andre. Calling any C Driver function after calling mongoc_cleanup is expected to fail. Can you confirm that, if you don't call any C Driver functions after calling mongoc_cleanup, then everything works as expected?

Comment by Hannes Magnusson [ 09/Nov/16 ]

Ahh, intersting. So mongoc_init() after a mongoc_cleanup(). Yes, I can see that being a problem.
I don't think we should assert on multiple mongoc_init(), that is "valid". But an init after cleanup is undefined behaviour...

Comment by andre maute [ 09/Nov/16 ]

Dear Hannes,

so here is our relevant stack trace,
as you can see there is NO indicator pointing to a mongoc function.

Essentially our code was
1. mongoc_init
2. mongoc_init
3. mongoc_cleanup
4. still use mongoc
5. mongoc_cleanup

After fixing, i.e. removing 2. and 3., the segfaults went away.
If we had had the requested assert within mongoc_init
we would have been alerted much earlier for inspecting the relevant code.

Additionally, we expect another problem (after inspecting the code)
with the sequence
1. mongoc_init
2. mongoc_cleanup
3. mongoc_init

Regards Andre

---- begin 'uname -a' ----
Linux user-VirtualBox 4.4.0-42-generic #62~14.04.1-Ubuntu SMP Fri Oct 7 23:15:48 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
---- end 'uname -a' ----

---- begin 'gcc -v' ----
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c+,java,go,d,fortran,objc,obj-c+ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
---- end 'gcc -v' ----

---- begin stack trace ----
Program received signal SIGABRT, Aborted.
0x00007ffff4b13c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff4b13c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff4b17028 in __GI_abort () at abort.c:89
#2 0x00007ffff4b502a4 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff4c5e6b0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff4b5aff7 in malloc_printerr (action=<optimized out>, str=0x7ffff4c5ea30 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:4996
#4 0x00007ffff5479529 in std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x0000000000f4eacd in Catch::SourceLineInfo::operator= (this=0x7fffffffda70) at /home/user/project/test/server/../catch.hpp:348
#6 0x0000000000f4eb58 in Catch::AssertionInfo::operator= (this=0x7fffffffda68) at /home/user/project/test/server/../catch.hpp:789
#7 0x0000000000f4ec69 in Catch::AssertionResult::operator= (this=0x7fffffffda68) at /home/user/project/test/server/../catch.hpp:812
#8 0x0000000000f4f072 in Catch::RunContext::assertionEnded (this=0x7fffffffda30, result=...) at /home/user/project/test/server/../catch.hpp:5727
#9 0x0000000000f2ed96 in Catch::ResultBuilder::handleResult (this=0x7fffffffcb20, result=...) at /home/user/project/test/server/../catch.hpp:7994
#10 0x0000000000f2ecb5 in Catch::ResultBuilder::captureExpression (this=0x7fffffffcb20) at /home/user/project/test/server/../catch.hpp:7990
#11 0x0000000000f2e607 in Catch::ResultBuilder::endExpression (this=0x7fffffffcb20) at /home/user/project/test/server/../catch.hpp:7952
#12 0x0000000000fca76c in Catch::ExpressionLhs<bool>::endExpression (this=0x7fffffffcb10) at /home/user/project/test/server/../catch.hpp:1809
#13 0x00000000013dfacb in resetDatabase () at /home/user/project/test/server/persistence/databasehelper.cpp:22
#14 0x00000000013d7b6e in ____C_A_T_C_H____T_E_S_T____9 () at /home/user/project/test/server/persistence/tst_gatewaydeletedjob.cpp:21
#15 0x0000000000f53bac in Catch::FreeFunctionTestCase::invoke (this=0x3e505d0) at /home/user/project/test/server/../catch.hpp:6297
#16 0x0000000000f28ba1 in Catch::TestCase::invoke (this=0x3e78eb0) at /home/user/project/test/server/../catch.hpp:7218
#17 0x0000000000f5184d in Catch::RunContext::invokeActiveTestCase (this=0x7fffffffda30) at /home/user/project/test/server/../catch.hpp:5891
#18 0x0000000000f5109a in Catch::RunContext::runCurrentTest (this=0x7fffffffda30, redirectedCout="", redirectedCerr="") at /home/user/project/test/server/../catch.hpp:5862
#19 0x0000000000f4e3ff in Catch::RunContext::runTest (this=0x7fffffffda30, testCase=...) at /home/user/project/test/server/../catch.hpp:5687
#20 0x0000000000f22fec in Catch::runTests (config=...) at /home/user/project/test/server/../catch.hpp:6030
#21 0x0000000000f52b6b in Catch::Session::run (this=0x7fffffffdc70) at /home/user/project/test/server/../catch.hpp:6138
#22 0x0000000000f52924 in Catch::Session::run (this=0x7fffffffdc70, argc=3, argv=0x7fffffffde68) at /home/user/project/test/server/../catch.hpp:6117
#23 0x0000000000f355a2 in main (argc=3, argv=0x7fffffffde68) at /home/user/project/test/server/../catch.hpp:10027
---- end stack trace ----

Am Dienstag, November 08, 2016 18:08 CET, "Hannes Magnusson (JIRA)" <jira@mongodb.org> schrieb:


sodge IT GmbH
Adlerstraße 5
72336 Balingen

Mail: andre.maute@sodgeit.de

URL: http://www.sodgeit.de
Telefon: +49-7433-95 59 28 4
Telefon: +49-7433-27 52 36
Fax: +49-7433-51 32

Sitz der Gesellschaft: Balingen
Registergericht: Amtsgericht Stuttgart HRB 740109
Geschäftsführer: Matthias Ehinger / David Feurle / Götz Martinek

Comment by Hannes Magnusson [ 08/Nov/16 ]

I think that would be helpful as I cannot see how this could happen, and I believe there are other underlaying factors that caused the segfault your are referring to.

Comment by andre maute [ 08/Nov/16 ]

at the moment not,
if in need, I might revert my fixes for our project and obfuscate our
customer's functionality.

Regards
Andre


sodge IT GmbH
Hauptwasen 8
72336 Balingen

Mail: andre.maute@sodgeit.de

URL: http://www.sodgeit.de
Mobil: +49-176-86 77 81 47
Telefon: +49-7433-95 59 28 4
Fax: +49-7433-95 59 28 5

Registergericht: Amtsgericht Stuttgart HRB 740109
Geschäftsführer: Matthias Ehinger / David Feurle / Götz Martinek

Comment by Hannes Magnusson [ 08/Nov/16 ]

Do you have the stacktrace from the segfault?
I'm curious what exactly happened and what it caused

Generated at Wed Feb 07 21:13:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.