[SERVER-33111] SCons split_dwarf tool can cause spurious object file rebuilds Created: 03/Feb/18  Updated: 29/Oct/23  Resolved: 20/Apr/19

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: 4.1.11

Type: Bug Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: Andrew Morrow (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File common.rebuilds     File no.dwo     File rebuilt.files.scons-3.0.1.master     File rebuilt.files.scons-3.0.1.r4.1.4    
Issue Links:
Depends
is depended on by SERVER-33661 Make /Zi default over /Z7 on msvc Closed
is depended on by SERVER-39997 Build test binaries that run on the s... Closed
Related
related to SERVER-21336 Should be possible to use CacheDir an... Closed
Backwards Compatibility: Fully Compatible
Operating System: Linux
Steps To Reproduce:

On a Linux machine:

> git checkout r4.0.4
> git clean -xfd
 
> /usr/bin/time python ./buildscripts/scons.py --ssl --install-mode=hygienic --implicit-cache -j 24 --disable-warnings-as-errors --modules= --variables-files= --link-model=dynamic CCFLAGS=-gsplit-dwarf build/install/bin/mongod --debug=explain
 
> /usr/bin/time python ./buildscripts/scons.py --ssl --install-mode=hygienic --implicit-cache -j 24 --disable-warnings-as-errors --modules= --variables-files= --link-model=dynamic CCFLAGS=-gsplit-dwarf build/install/bin/mongod --debug=explain

The second build will rebuild files, but it should not:

scons: done reading SConscript files.
scons: Building targets ...
scons: rebuilding `build/opt/mongo/base/shim.dwo' because:
           `src/mongo/base/shim.cpp' is no longer a dependency
           `src/mongo/base/shim.cpp' is a new dependency
Compiling build/opt/mongo/base/shim.os
scons: rebuilding `build/opt/mongo/base/data_type_terminated.dwo' because:
           `src/mongo/base/data_type_terminated.cpp' is no longer a dependency
           `src/mongo/base/data_type_terminated.cpp' is a new dependency
Compiling build/opt/mongo/base/data_type_terminated.os
scons: rebuilding `build/opt/mongo/util/net/hostandport_gen.dwo' because the dependency order changed:
               old: ['build/opt/mongo/util/net/hostandport_gen.cpp', '/usr/bin/g++', 'src/mongo/bson/bsonobjbuilder.h', ...

Sprint: Dev Tools 2019-01-14, Dev Tools 2019-01-28, Dev Tools 2019-02-11, Dev Tools 2019-03-25, Dev Tools 2019-04-08, Dev Tools 2019-04-22
Participants:

 Description   

When the split_dwarf tools is enabled, we sometimes observe that some object files get (identically) rebuilt on the second build, though not on subsequent builds.

We should figure out why, and fix it.



 Comments   
Comment by Githook User [ 20/Apr/19 ]

Author:

{'name': 'William Deegan', 'username': 'bdbaddog', 'email': 'bill@baddogconsulting.com'}

Message: SERVER-33111 Avoid spurious rebuilds when using -gsplit-dwarf

The issue was that builders with more than one target (potentially only when that 2nd or higher target is added in the emitter were not getting their implicit list cleared after a generated source is rebuilt. Thus leading to the implicit list order being incorrect when written to sconsign leaded to spurious rebuilds on second build

Closes #1307

Signed-off-by: Andrew Morrow <acm@mongodb.com>
Branch: master
https://github.com/mongodb/mongo/commit/7bf320d5aa34e3dd51c3a7f868e77025782dd359

Comment by Andrew Morrow (Inactive) [ 02/Apr/19 ]

OK, I went ahead and tested the latest. Here is the script I used:

#/bin/bash
 
set -o verbose
set -euxo pipefail
 
_CommonArgs="--cache-dir=$(pwd)/cache VERBOSE=0 --implicit-cache --link-model=dynamic --modules= --variables-files=etc/scons/mongodbtoolchain_stable_gcc.vars --dbg=on all ICECC=icecc -j300"
 
# no split dwarf, no cache, bfl off
git checkout bd/fix_server_33111_spurious_split_dwarf_builds
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_nocache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_nocache_nobfl_rebuild.log
 
 
 
# no split dwarf, no cache, bfl on
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_nocache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_nocache_bfl_rebuild.log
 
 
 
# split dwarf, no cache, bfl off
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_nobfl_rebuild.log
 
 
 
# split dwarf, no cache, bfl on
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_bfl_rebuild.log
 
 
 
 
 
 
 
 
 
 
# no split dwarf, cache, bfl off
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_cache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_cache_nobfl_rebuild.log
 
 
 
# no split dwarf, cache, bfl on
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_cache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_cache_bfl_rebuild.log
 
 
 
# split dwarf, cache, bfl off
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_nobfl_rebuild.log
 
 
 
# split dwarf, cache, bfl on
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_bfl_rebuild.log

At the time of testing, the indicated branch was checked out to https://github.com/bdbaddog/mongo/commit/71283f1928ab0023b48686de7d77bfd02e208268.

First, the great news is that we observed zero spurious rebuilds:

$ grep -c 'Compiling' *rebuild.log
nosplit_cache_bfl_rebuild.log:0
nosplit_cache_nobfl_rebuild.log:0
nosplit_nocache_bfl_rebuild.log:0
nosplit_nocache_nobfl_rebuild.log:0
split_cache_bfl_rebuild.log:0
split_cache_nobfl_rebuild.log:0
split_nocache_bfl_rebuild.log:0
split_nocache_nobfl_rebuild.log:0

As an extra check, we can see that SCons believed our one named target was up to date in all rebuilds:

$ grep 'is up to date' *rebuild.log
nosplit_cache_bfl_rebuild.log:scons: `all' is up to date.
nosplit_cache_nobfl_rebuild.log:scons: `all' is up to date.
nosplit_nocache_bfl_rebuild.log:scons: `all' is up to date.
nosplit_nocache_nobfl_rebuild.log:scons: `all' is up to date.
split_cache_bfl_rebuild.log:scons: `all' is up to date.
split_cache_nobfl_rebuild.log:scons: `all' is up to date.
split_nocache_bfl_rebuild.log:scons: `all' is up to date.
split_nocache_nobfl_rebuild.log:scons: `all' is up to date.

We got the following timing results:

$ tail -n 3 *build.log
==> nosplit_cache_bfl_build.log <==
scons: done building targets.
3614.90user 856.94system 16:04.00elapsed 463%CPU (0avgtext+0avgdata 1219144maxresident)k
0inputs+46516536outputs (28723major+100764602minor)pagefaults 0swaps
 
==> nosplit_cache_bfl_rebuild.log <==
scons: done building targets.
178.68user 1.57system 3:00.20elapsed 100%CPU (0avgtext+0avgdata 502648maxresident)k
0inputs+94472outputs (1major+561425minor)pagefaults 0swaps
 
==> nosplit_cache_nobfl_build.log <==
scons: done building targets.
2271.95user 727.44system 13:59.36elapsed 357%CPU (0avgtext+0avgdata 1134136maxresident)k
24inputs+44614848outputs (28716major+76569009minor)pagefaults 0swaps
 
==> nosplit_cache_nobfl_rebuild.log <==
scons: done building targets.
150.63user 4.32system 2:34.90elapsed 100%CPU (0avgtext+0avgdata 508648maxresident)k
0inputs+94488outputs (1major+373748minor)pagefaults 0swaps
 
==> nosplit_nocache_bfl_build.log <==
scons: done building targets.
2772.29user 765.22system 15:08.39elapsed 389%CPU (0avgtext+0avgdata 1227968maxresident)k
1408232inputs+24342800outputs (30448major+86845710minor)pagefaults 0swaps
 
==> nosplit_nocache_bfl_rebuild.log <==
scons: done building targets.
179.88user 1.54system 3:01.39elapsed 100%CPU (0avgtext+0avgdata 501824maxresident)k
0inputs+94448outputs (1major+561595minor)pagefaults 0swaps
 
==> nosplit_nocache_nobfl_build.log <==
scons: done building targets.
2555.16user 723.39system 13:50.41elapsed 394%CPU (0avgtext+0avgdata 1114320maxresident)k
128inputs+24107696outputs (28712major+80000472minor)pagefaults 0swaps
 
==> nosplit_nocache_nobfl_rebuild.log <==
scons: done building targets.
170.59user 5.02system 2:56.19elapsed 99%CPU (0avgtext+0avgdata 508056maxresident)k
32inputs+94440outputs (1major+388459minor)pagefaults 0swaps
 
==> split_cache_bfl_build.log <==
scons: done building targets.
3308.82user 892.00system 18:21.62elapsed 381%CPU (0avgtext+0avgdata 1683700maxresident)k
0inputs+30537000outputs (8936major+95591218minor)pagefaults 0swaps
 
==> split_cache_bfl_rebuild.log <==
scons: done building targets.
244.26user 2.02system 4:06.22elapsed 100%CPU (0avgtext+0avgdata 787008maxresident)k
0inputs+146776outputs (1major+700313minor)pagefaults 0swaps
 
==> split_cache_nobfl_build.log <==
scons: done building targets.
2776.44user 811.54system 15:12.04elapsed 393%CPU (0avgtext+0avgdata 1422760maxresident)k
0inputs+29795464outputs (8936major+86454607minor)pagefaults 0swaps
 
==> split_cache_nobfl_rebuild.log <==
scons: done building targets.
174.26user 3.60system 2:57.81elapsed 100%CPU (0avgtext+0avgdata 789712maxresident)k
0inputs+146744outputs (1major+683896minor)pagefaults 0swaps
 
==> split_nocache_bfl_build.log <==
scons: done building targets.
4131.52user 944.04system 18:20.56elapsed 461%CPU (0avgtext+0avgdata 1681280maxresident)k
8inputs+19137496outputs (8936major+111135028minor)pagefaults 0swaps
 
==> split_nocache_bfl_rebuild.log <==
scons: done building targets.
243.46user 2.13system 4:05.53elapsed 100%CPU (0avgtext+0avgdata 785944maxresident)k
0inputs+146704outputs (1major+739652minor)pagefaults 0swaps
 
==> split_nocache_nobfl_build.log <==
scons: done building targets.
2552.28user 762.02system 14:29.45elapsed 381%CPU (0avgtext+0avgdata 1473584maxresident)k
0inputs+16544872outputs (8936major+81914066minor)pagefaults 0swaps
 
==> split_nocache_nobfl_rebuild.log <==
scons: done building targets.
165.73user 3.35system 2:49.01elapsed 100%CPU (0avgtext+0avgdata 792288maxresident)k
0inputs+146744outputs (1major+606880minor)pagefaults 0swaps

I will put these in a table a little later. But the good news is that it looks like the proposed fix definitely resolves the issue.

Comment by bdbaddog#1 [ 28/Mar/19 ]

Hmm.. Does that mean that MD5-timestamp fix breaks checking if order of dependencies changed?

Comment by bdbaddog#1 [ 10/Feb/19 ]

@Mathew Robinson

If I'm understanding your comment about always running MD5, I think you may be slightly misreading the code.

The old logic md5's the executor content (not the file content) always.  The executor is more or less the action to build the target. So if the action changes it doesn't matter if the files have, it should still be rebuilt.

 

In the new and old logic if the timestamps hadn't changed we copy the old md5 (from sconsign load) to what will be written when sconsign is written at the end of the run.

 

The current issue seems to be tied to which File() object is being used. In one run it's the src dir, and the other it's the variantdir's version of it.  Since they are not the same python object (via id() check to dig into this), they compare as not equal. Even though they are in reality referring to the same source file (at least for your build as you have duplicate=0).

 

Initially it looked like there were two File() nodes referring to the same exact file, but that's theory's been proven incorrect.

 

So now to investigate why each run is getting different File() and why this (seems) to only happen when there are >= 1 additional targets added in the emitter.

So the recipe which seems to cause this (at least at this point in the investigation):

variantdir(), duplicate=0, emitter adding target, maybe target suffix unknown to consuming builder (linker consuming object files and also being handed the .dwo file), maybe combined with configure context.

 

 

Comment by Mathew Robinson (Inactive) [ 28/Jan/19 ]

I'm posting my last message from the Slack channel about this issue here for posterity:

It seems to me that in the old way of Deciding with the Timestamp-MD5 checker the MD5 check would always run and essentially overwrite the value of the Timestamp check: https://github.com/SCons/scons/blob/aa8c3a4fe2c22d95f23b0ab52cd483b55c370ae6/src/engine/SCons/Node/__init__.py#L1414

Now in the new way in 3.0.4 we return early if the timestamps match meaning we don't run the MD5 decider:
https://github.com/SCons/scons/blob/master/src/engine/SCons/Node/FS.py#L3358

I think this means there is a bug in the MD5 decider since we only see the rebuilds when explicitly using MD5 only now and would explain why we don't see it with the Timestamp-MD5 decider

Comment by Andrew Morrow (Inactive) [ 25/Jan/19 ]

As expected, running the above script checked out to 90cd49725f41354509dece813343c62e6ee9f533, which reverts to SCons 2.5.1, gets us the following results:

$ grep -c 'Compiling' *rebuild.log
nosplit_cache_bfl_rebuild.log:0
nosplit_cache_nobfl_rebuild.log:0
nosplit_nocache_bfl_rebuild.log:0
nosplit_nocache_nobfl_rebuild.log:0
split_cache_bfl_rebuild.log:61
split_cache_nobfl_rebuild.log:54
split_nocache_bfl_rebuild.log:56
split_nocache_nobfl_rebuild.log:54

In other words, we have the following matrix:

SCons Version Decider Spurious Builds?
2.5.1 MD5 Yes
2.5.1 MD5-Timestamp Yes
3.0.4 MD5 Yes
3.0.4 MD5-Timestamp No

So it appears that the changes made in SCons 3.0.4 to address SERVER-21336 only partially resolve this issue, and only when using the MD5-Timestmap decider. This suggests that somehow that new logic is papering over a deeper issue.

Comment by Andrew Morrow (Inactive) [ 25/Jan/19 ]

Some really interesting results after the SCons 3.0.4 upgrade yesterday. It appears that this bug no longer reproduces when using the MD5-Timestamp decider. However, it does reproduce when using the MD5 decider. I used the following script to test this against the MongoDB tree checked out to 5fb83f78b6740dbe3a771735e3629fec2a854a1d.

#/bin/bash
 
set -o verbose
set -o errexit
 
_CommonArgs="--cache-dir=$(pwd)/cache VERBOSE=0 -j12 --implicit-cache --disable-warnings-as-errors --install-mode=hygienic --link-model=dynamic --allocator=system --js-engine=none --modules= --variables-files= --dbg=off --opt=size install-embedded-dev install-embedded-test"
 
# no split dwarf, no cache, bfl off
git checkout master
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_nocache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_nocache_nobfl_rebuild.log
 
 
 
# no split dwarf, no cache, bfl on
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_nocache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_nocache_bfl_rebuild.log
 
 
 
# split dwarf, no cache, bfl off
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_nobfl_rebuild.log
 
 
 
# split dwarf, no cache, bfl on
git clean -xfd
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_nocache_bfl_rebuild.log
 
 
 
 
 
 
 
 
 
 
# no split dwarf, cache, bfl off
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_cache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off $_CommonArgs 2>&1 | tee ../nosplit_cache_nobfl_rebuild.log
 
 
 
# no split dwarf, cache, bfl on
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_cache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on $_CommonArgs 2>&1 | tee ../nosplit_cache_bfl_rebuild.log
 
 
 
# split dwarf, cache, bfl off
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_nobfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=off CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_nobfl_rebuild.log
 
 
 
# split dwarf, cache, bfl on
git clean -xfd
mkdir cache
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_bfl_build.log
/usr/bin/time python ./buildscripts/scons.py --cache --build-fast-and-loose=on CCFLAGS=-gsplit-dwarf $_CommonArgs 2>&1 | tee ../split_cache_bfl_rebuild.log

A quick grep shows us which builds had spurious recompiles:

$ grep -c 'Compiling' *rebuild.log
nosplit_cache_bfl_rebuild.log:0
nosplit_cache_nobfl_rebuild.log:0
nosplit_nocache_bfl_rebuild.log:0
nosplit_nocache_nobfl_rebuild.log:0
split_cache_bfl_rebuild.log:0
split_cache_nobfl_rebuild.log:58
split_nocache_bfl_rebuild.log:0
split_nocache_nobfl_rebuild.log:56

The conclusion is that:

  • Adding -gsplit-dwarf is required to trigger the spurious rebuilds.
  • Spurious rebuilds happen independently of whether the SCons cache is enabled.
  • Using the MD5-Timestamp decider gets no spurious rebuilds.
  • Using the MD5 decider gets spurious rebuilds.

This strongly suggests that the fix for SERVER-21336 suppresses this bug, but that it still exists.

I am going to re-test this with the commit right before the SCons 3.0.4 upgrade where we are still running SCons 2.5.1. My expectation is that we will see spurious rebuilds for all "split" cases, confirming that the fix for SERVER-21336 (or other SCons 3.0.4 changes) have partially addressed this issue.

Comment by Mathew Robinson (Inactive) [ 24/Jan/19 ]

bdbaddog You're correct I spoke to acm about this yesterday and I'm going to try and repro with the actual object files first then worry about the .so's later.

Comment by bdbaddog#1 [ 24/Jan/19 ]

@Matthew Robinson I don't think you're repro'd if the only rebuilds you are seeing are the .so's.

There should be a .dwo for each object file.

Andrew's issue (If I understand correctly) is that he's seeing spurious rebuilds of .o's and .dwo's.

In your build are you only seeing .so's rebuild?  What does the --explain=debug output say as the reason why?

Comment by Mathew Robinson (Inactive) [ 23/Jan/19 ]

When I got the spurious rebuilds I found the files which had been rebuilt on r4.1.4 and master with scons 3.0.1: rebuilt.files.scons-3.0.1.master rebuilt.files.scons-3.0.1.r4.1.4

Sorting and de-duping this files I was able to find the common files which were rebuilt: common.rebuilds

If I then search my build dir for a matching dwo file I find that 429 of the 430 common rebuilds do not have a dwo file: no.dwo

The split_dwarf site tool is adding a dwo file for every object file but we aren't generating a dwo file for every object file. So either we shouldn't be generating a dwo file for every object file, and the site tool should be able to determine that, or we're running an incorrect compiler command that causes certain files to not generate a dwo file.

I'm still new enough to split dwarf that I'm not sure at this point if we should be expecting a dwo for every object.

Comment by Mathew Robinson (Inactive) [ 23/Jan/19 ]

I was able to repro the issue. After full build switch to r4.1.4 and back to master I note that about 400 - 500 files get rebuilt.

Comment by Andrew Morrow (Inactive) [ 15/Jan/19 ]

mathew.robinson - Handing this off to you; CC bdbaddog, who can assist with investigation and probably write a fix once we have an RCA.

Comment by Andrew Morrow (Inactive) [ 20/Dec/18 ]

mathew.robinson - Could you please attempt the above repro on your local linux system and see if you get spurious rebuilds on the second build?

Comment by Andrew Morrow (Inactive) [ 15/Nov/18 ]

bdbaddog and mathew.robinson - Would be interesting to see if you can repro with the above instructions on your local linux systems.

Comment by Andrew Morrow (Inactive) [ 15/Nov/18 ]

bdbaddog - Updated this with repro instructions.

CC mathew.robinson.

Comment by Andrew Morrow (Inactive) [ 04/May/18 ]

See the comments in SERVER-21336 - the fix for that issue may also fix this issue.

Generated at Thu Feb 08 04:32:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.