Segfault on 1.1.2 whenever running PHP

[Zenexer]

On Ubuntu 15.10 x64:

% sudo php5-fpm -t || echo "Exit status: $?"
[27-Jan-2016 01:35:47] NOTICE: configuration file /etc/php5/fpm/php-fpm.conf test is successful

Exit status: 139

Here's an excerpt from catchsegv:

Backtrace:
php5-fpm[0x6dee88]
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so(+0x391b)[0x7f29ffd7491b]
/usr/lib/x86_64-linux-gnu/libsasl2.so.2(+0x6cc9)[0x7f2a07ba5cc9]
/usr/lib/x86_64-linux-gnu/libsasl2.so.2(sasl_client_done+0x2a)[0x7f2a07ba5e0a]
/usr/lib/php5/20131226/mongodb.so(+0x6122e)[0x7f2a003eb22e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xe36b)[0x7f2a0d3c036b]
/lib64/ld-linux-x86-64.so.2(+0x10bb7)[0x7f2a0fb96bb7]
/lib/x86_64-linux-gnu/libc.so.6(+0x39d32)[0x7f2a0d609d32]
/lib/x86_64-linux-gnu/libc.so.6(+0x39d85)[0x7f2a0d609d85]
php5-fpm(fpm_init+0x182)[0x7b9912]
php5-fpm(main+0x776)[0x465366]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f2a0d5f0a40]
php5-fpm(_start+0x29)[0x466539]

If I remove package libsasl2-dev before compiling, it works fine.

[jmikola]

Sorry for losing track of this issue. Was this using the mongodb extension installed through PECL or a separate package repository? Also, do you recall what exact versions of PHP and libsasl you were using at the time?

Fwiw, your stack trace looks a bit like an older segfault I encountered months ago (see: this comment), although I had more frames visible. If this is reproducible, is there any chance you can get a more detailed backtrace (e.g. bt full via gdb) from PHP with debug symbols installed and/or compiling the extension with:

phpize && ./configure --enable-developer-flags && make all && make install

[EugenMayer]

As Derik pointed out, its related to #258

Uninstalling libsasl2-dev and recompiling the extension using PECL: pecl install mongodb does indeed fix this.

The reason why most people have libsasl2-dev installed is, since memcached-dev depends on it, which is needed to install pecl install memached.

After reinstalling mongodb like described above, valgrind is clean:

valgrind --leak-check=full /usr/bin/php -S localhost:8085
==19935== Memcheck, a memory error detector
==19935== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==19935== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==19935== Command: /usr/bin/php -S localhost:8085
==19935==
PHP 5.5.33-1~dotdeb+7.1 Development Server started at Thu Mar 10 13:04:48 2016
Listening on http://localhost:8085
Document root is /root
Press Ctrl-C to quit.
^C==19935==
==19935== HEAP SUMMARY:
==19935== in use at exit: 109,428 bytes in 353 blocks
==19935== total heap usage: 37,385 allocs, 37,032 frees, 5,233,203 bytes allocated
==19935==
==19935== LEAK SUMMARY:
==19935== definitely lost: 0 bytes in 0 blocks
==19935== indirectly lost: 0 bytes in 0 blocks
==19935== possibly lost: 0 bytes in 0 blocks
==19935== still reachable: 109,428 bytes in 353 blocks
==19935== suppressed: 0 bytes in 0 blocks
==19935== Reachable blocks (those to which a pointer was found) are not shown.
==19935== To see them, rerun with: --leak-check=full --show-reachable=yes
==19935==
==19935== For counts of detected and suppressed errors, rerun with: -v
==19935== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 30 from 8)

[Zenexer]

@jmikola Straight from PECL on Ubuntu 15.10. I didn't do anything fancy. At the time I was using libsasl2 2.0.25, I believe, although that may be a more recent version.

[Zenexer]

The problem appears to be a little better with mongodb 1.1.4 from PECL and libsasl2 2.1.26. PHP-FPM isn't instantly crashing on every request now. Seeing almost identical output from catchsegv:

php5-fpm[0x6dee88]
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so(+0x391b)[0x7faa0704491b]
/usr/lib/x86_64-linux-gnu/libsasl2.so.2(+0x6cc9)[0x7faa0ee76cc9]
/usr/lib/x86_64-linux-gnu/libsasl2.so.2(sasl_client_done+0x2a)[0x7faa0ee76e0a]
/usr/lib/php5/20131226/mongodb.so(+0x6159e)[0x7faa076bb59e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xe36b)[0x7faa1469136b]
/lib64/ld-linux-x86-64.so.2(+0x10c07)[0x7faa16e68c07]
/lib/x86_64-linux-gnu/libc.so.6(+0x39d32)[0x7faa148dad32]
/lib/x86_64-linux-gnu/libc.so.6(+0x39d85)[0x7faa148dad85]
php5-fpm(fpm_init+0x182)[0x7b9912]
php5-fpm(main+0x776)[0x465366]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7faa148c1a40]
php5-fpm(_start+0x29)[0x466539]

make test failed; I'll assume either my environment is wrong or the tests aren't being maintained:

Number of tests :  229               228
Tests skipped   :    1 (  0.4%) --------
Tests warned    :    0 (  0.0%) (  0.0%)
Tests failed    :  212 ( 92.6%) ( 93.0%)
Expected fail   :    2 (  0.9%) (  0.9%)
Tests passed    :   14 (  6.1%) (  6.1%)

The list of failures is far too long to include here; I can drop it in gist if you'd like.

Here's an excessively verbose trace from gdb. Numbers 2, 3, and 4 are within libsasl2. Took a bit of hunting to find the debug symbol package for Ubuntu, but it's cyrus-sasl2-dbg. The library package lacks the "cyrus-" prefix.

#0  _zend_mm_free_int (heap=0xf2ef00, p=0x1030f20) at /build/php5-qbYJ0w/php5-5.6.11+dfsg/Zend/zend_alloc.c:2104
        mm_block = 0x1030f10
        next_block = 0x2061e30
        size = 16977696
#1  0x00007fffe886005e in php_phongo_free (mem=<optimized out>) at /home/paul/pecl-mongodb/mongodb-1.1.4/php_phongo.c:2342
No locals.
#2  0x00007fffe7fc0a73 in gssapi_common_mech_free (global_context=<optimized out>, utils=<optimized out>) at ../../plugins/gssapi.c:618
No locals.
#3  0x00007fffefffccc9 in client_done () at ../../lib/client.c:127
        cm = 0x1030fa0
        cprevm = 0x1030f50
#4  0x00007fffefffce0a in sasl_client_done () at ../../lib/client.c:87
        result = 1
#5  0x00007fffe884185e in _mongoc_do_cleanup () at /home/paul/pecl-mongodb/mongodb-1.1.4/src/libmongoc/src/mongoc/mongoc-init.c:130
No locals.
#6  0x00007ffff581736b in __pthread_once_slow (once_control=0x7fffe8a97d30 <once>, init_routine=0x7fffe8841850 <_mongoc_do_cleanup>) at pthread_once.c:114
        _buffer = {__routine = 0x7ffff58173c0 <clear_once_control>, __arg = 0x7fffe8a97d30 <once>, __canceltype = 73, __prev = 0x0}
        val = 0
        newval = <optimized out>
#7  0x00007ffff7de9c07 in _dl_fini () at dl-fini.c:252
        array = 0x7fffe8a8a908
        i = 1
        nmaps = 110
        nloaded = <optimized out>
        i = 74
        l = 0x100a320
        ns = 0
        maps = 0x7fffffffb9d0
        maps_size = 880
        do_audit = <optimized out>
        __PRETTY_FUNCTION__ = "_dl_fini"
#8  0x00007ffff5a60d32 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff5deb698 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
        atfct = <optimized out>
        onfct = <optimized out>
        cxafct = <optimized out>
        f = <optimized out>
#9  0x00007ffff5a60d85 in __GI_exit (status=status@entry=0) at exit.c:104
No locals.
#10 0x00000000007b9912 in fpm_init (argc=argc@entry=2, argv=argv@entry=0x7fffffffe6a8, config=<optimized out>, prefix=prefix@entry=0x0, pid=pid@entry=0x0, test_conf=test_conf@entry=1, 
    run_as_root=0, force_daemon=-1, force_stderr=0) at /build/php5-qbYJ0w/php5-5.6.11+dfsg/sapi/fpm/fpm/fpm.c:72
        __func__ = "fpm_init"
#11 0x0000000000465366 in main (argc=2, argv=0x7fffffffe6a8) at /build/php5-qbYJ0w/php5-5.6.11+dfsg/sapi/fpm/fpm/fpm_main.c:1941
        exit_status = 0
        c = -1
        use_extended_info = 0
        file_handle = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, 
                buf = 0x0, old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0, closer = 0x0}}, free_filename = 0 '\000'}
        orig_optind = 1
        orig_optarg = 0x0
        ini_entries_len = 0
        max_requests = 500
        requests = 0
        fcgi_fd = 0
        request = {listen_socket = 0, fd = 0, id = 0, keep = 0, closed = 0, in_len = 0, in_pad = 0, out_hdr = 0x0, out_pos = 0x0, out_buf = '\000' <repeats 3400 times>..., 
          reserved = "\250\346\377\377\377\177\000\000p\377\336\367\377\177\000", env = 0x1}
        fpm_config = 0x0
        fpm_prefix = 0x0
        fpm_pid = 0x0
        test_conf = 1
        force_daemon = -1
        force_stderr = 0
        php_information = 0
        php_allow_to_run_as_root = 0
        __func__ = "main"

Relevant code from mongo-init.c:

static MONGOC_ONCE_FUN( _mongoc_do_cleanup)
{
#ifdef MONGOC_ENABLE_SSL
   _mongoc_ssl_cleanup();
#endif

#ifdef MONGOC_ENABLE_SASL
#ifdef MONGOC_HAVE_SASL_CLIENT_DONE
   sasl_client_done ();  /* Line 130; this is where it's segfaulting */
#else
   /* fall back to deprecated function */
   sasl_done ();
#endif
#endif

#ifdef _WIN32
   WSACleanup ();
#endif

   _mongoc_counters_cleanup ();

   MONGOC_ONCE_RETURN;
}

And php_mongo.c:

static void php_phongo_free(void *mem) /* {{{ */
{
    if (mem) {
        efree(mem);  /* Line 2342; this is where it's segfaulting */
    }
} /* }}} */

[Zenexer]

Here's the code from frame 2:

static void gssapi_common_mech_free(void *global_context __attribute__((unused)),
                    const sasl_utils_t *utils)
{
#ifdef GSS_USE_MUTEXES
    if (gss_mutex) {
      utils->mutex_free(gss_mutex);  /* SEGV */
      gss_mutex=NULL;
    }
#endif
}

And then we follow the breadcrumbs:

(gdb) p utils->mutex_free
$5 = (sasl_mutex_free_t *) 0x7fffe88417f0 <mongoc_sasl_mutex_free>

/* mongo-init.c */
static void
mongoc_sasl_mutex_free (void *mutex)
{
   mongoc_mutex_destroy ((mongoc_mutex_t *) mutex);
   bson_free (mutex);  /* SEGV */
}

/* bson-memory.c */
void
bson_free (void *mem) /* IN */
{
   gMemVtable.free (mem);  /* SEGV */
}

(gdb) p gMemVtable.free
$1 = (void (*)(void *)) 0x7fffe8860050 <php_phongo_free>

Which brings us back to php_phongo_free.

mongoc_mutex_destroy is a macro for pthread_mutex_destroy.

[Zenexer]

I could be completely misunderstanding this, but why is bson_free being called? If a mutex managed via the mongoc_* methods is really just a pthread mutex without any sort of wrapper, it doesn't make sense to free it through libbson.

Edit

Never mind; according to valgrind, the relevant memory is allocated with bson_malloc0. (A memory leak is reported because the memory isn't freed before the segfault occurs.) Interestingly, freeing the mutex with a simple call to free works fine and fixes the memory leak. Could this mean the bug is actually in libbson or Zend?

[Zenexer]

zend_alloc.c:

static void _zend_mm_free_int(zend_mm_heap *heap, void *p ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)
{
    /*
    (gdb) p *heap
    $6 = {use_zend_alloc = 1, _malloc = 0x0, _free = 0x0, _realloc = 0x0, free_bitmap = 0, large_free_bitmap = 131072, block_size = 262144, compact_size = 2097152, segments_list = 0x7ffff7f1e010, 
      storage = 0xf2eee0, real_size = 262144, real_peak = 262144, limit = 25165824, size = 9120, peak = 9120, reserve_size = 8192, reserve = 0x7ffff7f1e030, overflow = 0, internal = 0, cached = 856, 
      cache = {0x7ffff7f202d8, 0x7ffff7f20378, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7ffff7f20068, 0x0 <repeats 53 times>, 0x7ffff7f200c8, 0x0}, free_buckets = {0xf2f188, 0xf2f188, 0xf2f198, 0xf2f198, 
        0xf2f1a8, 0xf2f1a8, 0xf2f1b8, 0xf2f1b8, 0xf2f1c8, 0xf2f1c8, 0xf2f1d8, 0xf2f1d8, 0xf2f1e8, 0xf2f1e8, 0xf2f1f8, 0xf2f1f8, 0xf2f208, 0xf2f208, 0xf2f218, 0xf2f218, 0xf2f228, 0xf2f228, 0xf2f238, 
        0xf2f238, 0xf2f248, 0xf2f248, 0xf2f258, 0xf2f258, 0xf2f268, 0xf2f268, 0xf2f278, 0xf2f278, 0xf2f288, 0xf2f288, 0xf2f298, 0xf2f298, 0xf2f2a8, 0xf2f2a8, 0xf2f2b8, 0xf2f2b8, 0xf2f2c8, 0xf2f2c8, 
        0xf2f2d8, 0xf2f2d8, 0xf2f2e8, 0xf2f2e8, 0xf2f2f8, 0xf2f2f8, 0xf2f308, 0xf2f308, 0xf2f318, 0xf2f318, 0xf2f328, 0xf2f328, 0xf2f338, 0xf2f338, 0xf2f348, 0xf2f348, 0xf2f358, 0xf2f358, 0xf2f368, 
        0xf2f368, 0xf2f378, 0xf2f378, 0xf2f388, 0xf2f388, 0xf2f398, 0xf2f398, 0xf2f3a8, 0xf2f3a8, 0xf2f3b8, 0xf2f3b8, 0xf2f3c8, 0xf2f3c8, 0xf2f3d8, 0xf2f3d8, 0xf2f3e8, 0xf2f3e8, 0xf2f3f8, 0xf2f3f8, 
        0xf2f408, 0xf2f408, 0xf2f418, 0xf2f418, 0xf2f428, 0xf2f428, 0xf2f438, 0xf2f438, 0xf2f448, 0xf2f448, 0xf2f458, 0xf2f458, 0xf2f468, 0xf2f468, 0xf2f478, 0xf2f478, 0xf2f488, 0xf2f488, 0xf2f498, 
        0xf2f498, 0xf2f4a8, 0xf2f4a8, 0xf2f4b8, 0xf2f4b8, 0xf2f4c8, 0xf2f4c8, 0xf2f4d8, 0xf2f4d8, 0xf2f4e8, 0xf2f4e8, 0xf2f4f8, 0xf2f4f8, 0xf2f508, 0xf2f508, 0xf2f518, 0xf2f518, 0xf2f528, 0xf2f528, 
        0xf2f538, 0xf2f538, 0xf2f548, 0xf2f548, 0xf2f558, 0xf2f558, 0xf2f568, 0xf2f568, 0xf2f578, 0xf2f578}, large_free_buckets = {0x0 <repeats 17 times>, 0x7ffff7f203c0, 0x0 <repeats 46 times>}, 
      rest_buckets = {0xf2f788, 0xf2f788}, rest_count = 0}
    (gdb) p p
    $17 = (void *) 0x1030f30
    (gdb) p/d p
    $18 = 16977712
    */
    zend_mm_block *mm_block;
    zend_mm_block *next_block;
    size_t size;
#ifdef ZEND_SIGNALS
    TSRMLS_FETCH();
#endif
    /*
    # define ZEND_MM_VALID_PTR(block) \
        zend_mm_check_ptr(heap, block, 1 ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC)
    */
    if (!ZEND_MM_VALID_PTR(p)) {
        return;
    }

    HANDLE_BLOCK_INTERRUPTIONS();

    /*
    #define ZEND_MM_ALIGNMENT               8
    #define ZEND_MM_ALIGNMENT_MASK          ~(ZEND_MM_ALIGNMENT-1)
    #define ZEND_MM_ALIGNED_SIZE(size)      (((size) + ZEND_MM_ALIGNMENT - 1) & ZEND_MM_ALIGNMENT_MASK)
    sizeof(zend_mm_block) = 16
    #define ZEND_MM_ALIGNED_HEADER_SIZE     ZEND_MM_ALIGNED_SIZE(sizeof(zend_mm_block))
    #define ZEND_MM_BLOCK_AT(blk, offset)   ((zend_mm_block *) (((char *) (blk))+(offset)))
    #define ZEND_MM_HEADER_OF(blk)          ZEND_MM_BLOCK_AT(blk, -(int)ZEND_MM_ALIGNED_HEADER_SIZE)
    */
    mm_block = ZEND_MM_HEADER_OF(p);      /* {info = {_size = 16977712, _prev = 49}} */
    /*
    #define ZEND_MM_BLOCK_SIZE(b)           ((b)->info._size & ~ZEND_MM_TYPE_MASK)
    */
    size = ZEND_MM_BLOCK_SIZE(mm_block);  /* 16977712 (0x1030f30) */
    ZEND_MM_CHECK_PROTECTION(mm_block);

#if ZEND_DEBUG || ZEND_MM_HEAP_PROTECTION
    memset(ZEND_MM_DATA_OF(mm_block), 0x5a, mm_block->debug.size);
#endif

#if ZEND_MM_CACHE
    if (EXPECTED(ZEND_MM_SMALL_SIZE(size)) && EXPECTED(heap->cached < ZEND_MM_CACHE_SIZE)) {
        size_t index = ZEND_MM_BUCKET_INDEX(size);
        zend_mm_free_block **cache = &heap->cache[index];

        ((zend_mm_free_block*)mm_block)->prev_free_block = *cache;
        *cache = (zend_mm_free_block*)mm_block;
        heap->cached += size;
        ZEND_MM_SET_MAGIC(mm_block, MEM_BLOCK_CACHED);
#if ZEND_MM_CACHE_STAT
        if (++heap->cache_stat[index].count > heap->cache_stat[index].max_count) {
            heap->cache_stat[index].max_count = heap->cache_stat[index].count;
        }
#endif
        HANDLE_UNBLOCK_INTERRUPTIONS();
        return;
    }
#endif

    /*
    heap->size = 9120
    size = 16977712 (0x1030f30)
    */
    heap->size -= size;
    /*
    heap->size = 18446744073692583024 (0xfffffffffefd1470)
    */

    /*
    #define ZEND_MM_IS_FREE_BLOCK(b)        (!((b)->info._size & ZEND_MM_USED_BLOCK))
    #define ZEND_MM_BLOCK_AT(blk, offset)   ((zend_mm_block *) (((char *) (blk))+(offset)))
    */

    next_block = ZEND_MM_BLOCK_AT(mm_block, size);
    if (ZEND_MM_IS_FREE_BLOCK(next_block)) {  /* SEGV */
        zend_mm_remove_from_free_list(heap, (zend_mm_free_block *) next_block);
        size += ZEND_MM_FREE_BLOCK_SIZE(next_block);
    }
    if (ZEND_MM_PREV_BLOCK_IS_FREE(mm_block)) {
        mm_block = ZEND_MM_PREV_BLOCK(mm_block);
        zend_mm_remove_from_free_list(heap, (zend_mm_free_block *) mm_block);
        size += ZEND_MM_FREE_BLOCK_SIZE(mm_block);
    }
    if (ZEND_MM_IS_FIRST_BLOCK(mm_block) &&
        ZEND_MM_IS_GUARD_BLOCK(ZEND_MM_BLOCK_AT(mm_block, size))) {
        zend_mm_del_segment(heap, (zend_mm_segment *) ((char *)mm_block - ZEND_MM_ALIGNED_SEGMENT_SIZE));
    } else {
        ZEND_MM_BLOCK(mm_block, ZEND_MM_FREE_BLOCK, size);
        zend_mm_add_to_free_list(heap, (zend_mm_free_block *) mm_block);
    }
    HANDLE_UNBLOCK_INTERRUPTIONS();
}

I'm not sure exactly how these zend_mm_block things work, but p doesn't seem to point to one. It points to the pthread mutex:

(gdb) p gss_mutex
$27 = (void *) 0x1030f30
(gdb) p/d gss_mutex
$28 = 16977712

ZEND_MM_VALID_PTR doesn't seem to be doing its job. However, if it did detect that the pointer wasn't to a zend_mm_block, the memory still wouldn't be freed. My primitive understanding of C tells me that free needs to be used instead of bson_free. Of course, there's a catch: the relevant function isn't in pecl-mongodb. bson_free calls php_phongo_free which calls efree, but changing that to free would certainly break other aspects of the extension that use PHP's memory management.

[bjori]

Huge props for you investigation. From skimming your comments, I think phongo is restoring the libbson memory handler to late.

Whatever mongoc_init() allocates before phongo calls bson_mem_set_vtable needs to be freed using whatever memory manager that was used.

mongoc does however register atexit() to cleanup after itself on exit, in case its ´mongoc_cleanup()´ routine isn't called. If that happens though, phongo doesn't restore the memory manager, and will happily attempt to free from the zmm whatever mongoc is trying to free.

So, I'm very curious, how is that exit() triggered? Why is the process straight up exiting rather then hitting the normal shutdown routines?

[bjori]

Could you try recompiling the extension with CFLAGS=-DMONGOC_NO_AUTOMATIC_GLOBALS

Something like this should probably work:

$ git clone https://github.com/mongodb/mongo-php-driver.git
$ cd mongo-php-driver
$ git submodule update --init
$ phpize
$ CFLAGS=-DMONGOC_NO_AUTOMATIC_GLOBALS ./configure --with-mongodb-sasl
$ make -j4
$ sudo mv /usr/lib/php5/20131226/mongodb.so /usr/lib/php5/20131226/mongodb-original.so
$ sudo cp modules/mongodb.so /usr/lib/php5/20131226/mongodb.so
$ sudo service php5-fpm restart

[Zenexer]

MONGOC_NO_AUTOMATIC_GLOBALS seems to fix it.

php5-fpm -t may have an abnormal exit routine because it doesn't actually run any PHP; it just checks that php.ini is valid. I'm not sure how that's implemented behind-the-scenes, but presumably it could be taking some shortcuts.

There's also the opcache.fast_shutdown option. We've experimented with it a bit and never found it to cause problems in the past. so we've left it on. According to the documentation, that option does interfere with how memory is released (or not released).

[EugenMayer]

opcache.fast_shutdown=1 or opcache.fast_shutdown=0 do both not fix / cause this issues, i tested this.

you can use the php daemon mode to test the shutdown
/usr/bin/php -S localhost:8085

Also you can use valgrind to ensure the leak is fixed:

export USE_ZEND_ALLOC=0
export ZEND_DONT_UNLOAD_MODULES=1
valgrind --leak-check=full /usr/bin/php -S localhost:8085

Also this bug is triggered without any PHP script, its the garbage-collector called for every fpm fork.
So you can even reproduce it without stopping fpm, by simply start forks and let them debootstrap again due to max_childs

I was yet not able to verify if -DMONGOC_NO_AUTOMATIC_GLOBALS does fix it for us too.