mongodb-3.4.3-1.fc27 fails to build in F27 because all tests fail: [executor:cpp_unit_test] 2017-05-18T15:55:08.509+0000 Summary: 316 test(s) ran in 526.01 seconds (0 succeeded, 0 were skipped, 316 failed, 0 errored) The following tests failed (with exit code): build/opt/mongo/base/base_test (-11) build/opt/mongo/base/secure_allocator_test (-11) build/opt/mongo/base/system_error_test (-11) [...] A difference between working and failing build root is: gperftools-devel 2.5-5.fc26 > 2.5.91-1.fc27 libpcap-devel 14:1.8.1-3.fc26 > 14:1.8.1-4.fc27 libacl 2.2.52-13.fc26 > 2.2.52-15.fc27 gperftools-libs 2.5-5.fc26 > 2.5.91-1.fc27 libblkid 2.29.1-2.fc26 > 2.30-0.1.fc27 libmount 2.29.1-2.fc26 > 2.30-0.1.fc27 python2 2.7.13-8.fc27 > 2.7.13-9.fc27 libpcap 14:1.8.1-3.fc26 > 14:1.8.1-4.fc27 util-linux 2.29.1-2.fc26 > 2.30-0.1.fc27 python2-libs 2.7.13-8.fc27 > 2.7.13-9.fc27 perl-Unicode-Normalize 1.25-366.fc26 > 1.25-367.fc27 libuuid 2.29.1-2.fc26 > 2.30-0.1.fc27 libsmartcols 2.29.1-2.fc26 > 2.30-0.1.fc27 device-mapper-libs 1.02.140-1.fc27 > 1.02.140-2.fc27 libfdisk 2.29.1-2.fc26 > 2.30-0.1.fc27 coreutils 8.27-8.fc27 > 8.27-9.fc27 coreutils-common 8.27-8.fc27 > 8.27-9.fc27 p11-kit 0.23.5-1.fc27 > 0.23.5-2.fc27 kernel-headers 4.12.0-0.rc0.git9.1.... > 4.12.0-0.rc1.git1.1.... p11-kit-trust 0.23.5-1.fc27 > 0.23.5-2.fc27 device-mapper 1.02.140-1.fc27 > 1.02.140-2.fc27 libusbx > 1.0.21-2.fc26 system-python 3.6.1-6.fc27 > 3.6.1-7.fc27 glib2 2.52.2-1.fc27 > 2.52.2-2.fc27 fedora-repos 27-0.1 > 27-0.2 libcurl 7.54.0-4.fc27 > 7.54.0-5.fc27 python3-libs 3.6.1-6.fc27 > 3.6.1-7.fc27 gnutls 3.5.12-1.fc27 > 3.5.12-2.fc27 fedora-release 27-0.1 > 27-0.2 curl 7.54.0-4.fc27 > 7.54.0-5.fc27 python3 3.6.1-6.fc27 > 3.6.1-7.fc27 gnupg2 2.1.20-2.fc27 > 2.1.21-2.fc27 acl 2.2.52-13.fc26 > 2.2.52-15.fc27 system-python-libs 3.6.1-6.fc27 > 3.6.1-7.fc27 fedora-repos-rawhide 27-0.1 > 27-0.2 This happens on all platforms.
If "(-11)" means SIGSEGV, then this is the same bug I see when starting already built mongodb server in perl-MongoDB tests <https://apps.fedoraproject.org/koschei/build/2901232>: + mkdir test_db + mongod --fork --logpath /builddir/build/BUILD/MongoDB-v1.8.0/mongod.log --pidfilepath /builddir/build/BUILD/MongoDB-v1.8.0/mongod.pid --dbpath /builddir/build/BUILD/MongoDB-v1.8.0/test_db/ --smallfiles mongod: Relink `/lib64/libsnappy.so.1' with `/lib64/libtcmalloc.so.4' for IFUNC symbol `_ZdlPvm' /var/tmp/rpm-tmp.h8x2hY: line 33: 18506 Segmentation fault (core dumped) mongod --fork --logpath $PWD/mongod.log --pidfilepath $PWD/mongod.pid --dbpath $PWD/test_db/ --smallfiles
Maybe it's a dynamic linker bug #1452813.
(In reply to Petr Pisar from comment #2) > Maybe it's a dynamic linker bug #1452813. The error message looks suspiciously similar. However the way to be sure would be to set the environment variable export LD_DEBUG=all and check the last few lines of output. (Compare with https://bugzilla.redhat.com/show_bug.cgi?id=1452813#c2)
Having installed: mongodb-server-3.4.3-1.fc27.x86_64 snappy-1.1.4-3.fc26.x86_64 gperftools-libs-2.5.91-1.fc27.x86_64 glibc-2.25.90-2.fc27.x86_64 $ LD_DEBUG=all mongod --fork --logpath /tmp/mongod.log --pidfilepath /tmp/mongod.pid --dbpath /tmp --smallfiles [...] 18936: symbol=_ZdlPvm; lookup in file=mongod [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libpcre.so.1 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libpcrecpp.so.0 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libyaml-cpp.so.0.5 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libstemmer.so.0 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libz.so.1 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libicudata.so.57 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libicui18n.so.57 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libicuuc.so.57 [0] 18936: symbol=_ZdlPvm; lookup in file=/lib64/libtcmalloc.so.4 [0] 18936: binding file /lib64/libsnappy.so.1 [0] to /lib64/libtcmalloc.so.4 [0]: normal symbol `_ZdlPvm' [CXXABI_1.3.9] mongod: Relink `/lib64/libsnappy.so.1' with `/lib64/libtcmalloc.so.4' for IFUNC symbol `_ZdlPvm' Segmentation fault (core dumped)
Probably a regression of bug 1312462.
The back trace point to ld-linux.so: #0 0x0000000000000000 in ?? () #1 0x00007f8301842760 in ?? () #2 0x00007fffffffe370 in ?? () #3 0x00007f8301843f05 in ?? () #4 0x0000000000000001 in ?? () #5 0x00007f8304a2b14a in elf_machine_rela (skip_ifunc=<optimized out>, reloc_addr_arg=0x7f8300847f00, version=<optimized out>, sym=<optimized out>, reloc=0x7f8300642ff8, map=0x7f8304c2e920) at ../sysdeps/x86_64/dl-machine.h:349 #6 elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=<optimized out>, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x7f8304c2e920) at do-rel.h:137 #7 _dl_relocate_object (scope=<optimized out>, reloc_mode=<optimized out>, consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:259 #8 0x00007f8304a21e1a in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2047 #9 0x00007f8304a3843b in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffe590, dl_main=dl_main@entry=0x7f8304a1fbc0 <dl_main>) at ../elf/dl-sysdep.c:253 #10 0x00007f8304a23078 in _dl_start_final (arg=0x7fffffffe590) at rtld.c:303 #11 _dl_start (arg=0x7fffffffe590) at rtld.c:409 #12 0x00007f8304a1ee68 in _start () from /lib64/ld-linux-x86-64.so.2 #13 0x0000000000000009 in ?? () [...]
That's very similar to: https://bugzilla.redhat.com/show_bug.cgi?id=1452813#c1 Suggest marking this bug as a duplicate and reassigning the other bug to gperftools. I'm still seeing if a simple rebuild of the affected packages fixes things or not.
In fact, let's just do that ... *** This bug has been marked as a duplicate of bug 1452813 ***