|
Here is another case where the presence of a gdb index appears to inhibit correct symbol resolution. I have only tested the behavior for a core dump because that is all I can ever reliably get diagnostics from out of Evergreen.
$ git rev-parse HEAD
|
20ce7b7dd990c1e34d735594afdccccad1bfb0a3
|
$ python ./buildscripts/scons.py --modules= --dbg=off --opt=on --link-model=dynamic --variables-files=./etc/scons/mongodbtoolchain_stable_gcc.vars --variables-files=./etc/scons/experimental_unified_ninja.vars --ninja ICECC=icecc CCACHE=ccache
|
$ ./build/install/bin/mongod --replSet rs --setParameter writePeriodicNoops=0
|
$ /opt/mongodbtoolchain/v4/bin/gcore $(pidof mongod)
|
$ /opt/mongodbtoolchain/v4/bin/gdb ~/mongo/build/install/bin/mongod ~/mongo/core.18556
|
The behavior I observe is that pretty printing for absl::node_hash_map fails for the ResourceCatalog::_resources member. Note that here the 0x5650fd068450 address corresponds to the address of the ResourceCatalog decoration on the global ServiceContext. One way of learning this address would be to run print *'mongo::(anonymous namespace)::globalServiceContext'. However, please be aware a new gdb session must be launched after learning the address of the ResourceCatalog decoration on the global ServiceContext when done this way in order to successfully reproduce the issue.
(gdb) print *(mongo::ResourceCatalog*)0x5650fd068450
|
$1 = {
|
_mutex = { ... },
|
_resources = absl::node_hash_map<mongo::ResourceId, absl::lts_20210324::flat_hash_set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, mongo::StringMapHasher, mongo::StringMapEq, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> with 26 elems Traceback (most recent call last):
|
File "buildscripts/gdb/mongo_printers.py", line 557, in children
|
yield ('key', kvp['first'])
|
gdb.error: There is no member named first.
|
|
}
|
Resolving the symbol for the constructor function of the ResourceCatalog decoration on the global ServiceContext inexplicably causes subsequent printing of the ResourceCatalog to behave as desired. This is related to why print *'mongo::(anonymous namespace)::globalServiceContext' masks the issue. Type.__str__() is called on the constructor function in the decoration pretty printer which resolves the constructor function's symbol too. Instead, it ought to be possible to pretty print an absl::node_hash_map without first loading a symbol that happens to be in the same objfile.
(gdb) python print(gdb.lookup_symbol('mongo::DecorationRegistry<mongo::ServiceContext>::constructAt<mongo::ResourceCatalog>(void*)'))
|
(<gdb.Symbol object at 0x7febc41572a0>, False)
|
(gdb) print *(mongo::ResourceCatalog*)0x5650fd068450
|
$2 = {
|
_mutex = { ... },
|
_resources = absl::node_hash_map<mongo::ResourceId, absl::lts_20210324::flat_hash_set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, mongo::StringMapHasher, mongo::StringMapEq, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> with 26 elems = {
|
[{
|
_fullHash = 6954839166662517174
|
}] = absl::flat_hash_set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >> with 1 elems = {"local.startup_log"},
|
[{
|
_fullHash = 5880577798165183548
|
}] = absl::flat_hash_set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >> with 1 elems = {"admin"},
|
...
|
}
|
}
|
|
~/.gdbinit
|
add-auto-load-safe-path /
|
|
set pagination off
|
set print object on
|
set print pretty on
|
set print static-members off
|
|