Loading...
Loading...
unittest/unittest_test fails in MongoDB 4.0 - output is attached. Or is something special needed to be able to print stacktrace properly?
acm commented on Wed, 18 Jul 2018 14:17:28 +0000: Thanks mskalick - Some of those flags do look interesting. I've filed SERVER-36176, SERVER-36177, and SERVER-36178 to propose that we make some of those the defaults in our builds as well. Is there anything more we can do for you in this ticket, or can we close it out? mskalick commented on Thu, 12 Jul 2018 18:57:27 +0000: Thanks both of you for deep analysis. Removing "-fvisibility=hidden" fixed the unit test failure. I'm sorry, but I don't know much about mentioned gcc flags - as it was noted, they are distribution default. They are described in https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ . I don't know about performance impact so I asked in this thread, so I hope some gcc person will reply. To note: I'm going to have two week PTO. I'll return to this after it. mark.benvenuto commented on Thu, 12 Jul 2018 18:38:59 +0000: Here is Fedora's discussion about their default options: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WYREDEDXEE57GESAB3TTYDG6S5OIX4ZN/ mark.benvenuto commented on Mon, 9 Jul 2018 15:30:16 +0000: There are only 3 flags that are added in the spec file for MongoDB. The rest are system-wide RPM build defaults for Fedora. https://src.fedoraproject.org/rpms/mongodb/blob/master/f/mongodb.spec#_233-234 cat > variables.list << EOF CCFLAGS="$(echo %{?optflags} | sed -e "s/-O. //" -e "s/-g //") -fvisibility=hidden" LINKFLAGS="%{?__global_ldflags} -Wl,-z,noexecstack -Wl,--reduce-memory-overheads,--no-keep-memory" VERBOSE=1 MONGO_VERSION="%{version}" VARIANT_DIR="fedora" acm commented on Mon, 9 Jul 2018 14:39:40 +0000: mskalick - Looking at that list of flags, there are several things that I think you either shouldn't do, or don't need to do, when building 4.0: -pipe doesn't do anything useful on modern systems. -Wall automatically included by the MongoDB build system. -Werror=... -Werror is automatically included by the MongoDB build system. _FORTIFY_SOURCE=2 is automatically added by the MongoDB build system unless --runtime-hardening=off is passed to SCons. -fstack-protector-strong is automatically added by the MongoDB build system unless --runtime-hardening=off is passed to SCons. -Wl,-z,relro is automatically added by the MongoDB build system unless --runtime-hardening=off is passed to SCons. -Wl,-z,now is automatically added by the MongoDB build system. -Wl,-z,noexecstack is automatically added by the MongoDB build system, as is -Wl,--warn-execstack. -m64 should be unnecessary unless you are doing a cross build of some sort. I don't know what is in those various hardening scripts, so hard to say what they do. I am somewhat interested in whether you think we should be applying these flags for our hardened builds. Do you have some guidance on the runtime costs? -fstack-clash-protection -D_GLIBCXX_ASSERTIONS -fcf-protection I'm also curious about why you are applying -fexceptions and -fasynchronous-unwind-tables. The first seems unnecessary for a C++ project, and the second seems potentially interesting, if you have some context on why it is applied. mark.benvenuto commented on Thu, 5 Jul 2018 16:00:01 +0000: mskalick The problem is the "-fvisibility=hidden" flag which was introduced in this commit. If you remove this flag, the unittest will pass. Removing this flag will be beneficial since MongoDB automatically prints stack traces which allows us to often quickly troubleshoot many issues before loading crash dumps in the debugger. mark.benvenuto commented on Tue, 3 Jul 2018 23:11:48 +0000: mskalick Using Koji, I grabbed a 4.0 build, and examined how it was compiling. Here is the variables I found in the Koji logs: CCFLAGS="-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fvisibility=hidden" LINKFLAGS="-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-z,noexecstack -Wl,--reduce-memory-overheads,--no-keep-memory" VERBOSE=1 MONGO_VERSION="4.0.0" VARIANT_DIR="fedora" I found that both MongoDB 4.0 on Fedora 28 with gcc-8.1.1-1.fc28 and binutils-2.29.1-23.fc28 and the official mongodb-3.6.3-1.fc28 package both fail to print mongod function names when I send SIGTERM to mongod. This means that one or more of these flags is causing dladdr to not find the function name. It will take me some time to isolate the problematic flag. acm commented on Tue, 3 Jul 2018 16:23:08 +0000: mskalick - We don't do anything particular to achieve that, usually. We hard code that we link with -rdynamic in the top level Sconstruct (look for env.Append(LINKFLAGS=['-rdynamic'])) to ensure that the backtracer is able to find symbols. I'm not aware of any other options. If you downgrade to GCC 7, does this test pass on that same system? mskalick commented on Tue, 3 Jul 2018 06:36:57 +0000: The exception happens because the backtrace code cannot resolve the names of almost any symbols in the unittest binary. And what compiler or whatever options are needed to get resolvable names of symbols? mark.benvenuto commented on Mon, 2 Jul 2018 15:29:07 +0000: The exception message is: Expected to find "printStackTrace" (printStackTrace) in stacktrace The exception happens because the backtrace code cannot resolve the names of almost any symbols in the unittest binary.
$ cat build-options -j4 --use-system-pcre --use-system-boost --use-system-snappy --use-system-valgrind --use-system-zlib --use-system-stemmer --use-system-tcmalloc --use-system-yaml --mmapv1=on --wiredtiger=on --ssl --nostrip --disable-warnings-as-errors --variables-files=variables.list $ scons $(cat build-options) build/fedora/mongo/unittest/unittest_test --opt=off
Click on a version to see all relevant bugs
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.