[SERVER-71098] Create additional gdb tests Created: 04/Nov/22  Updated: 23/Jan/24

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Mira Carey Assignee: Daniel Moody
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-59856 Hang analyzer gdb script raises gdb.e... Backlog
related to SERVER-50476 gdb.lookup_type on dynamically linked... Closed
related to SERVER-71211 gdb-index causing bugs in server gdb Closed
is related to SERVER-75936 Avoid hardcoded version number in abs... Backlog
Assigned Teams:
Build
Sprint: Build and Correctness OnDeck
Participants:

 Description   

We should create a framework for and write some gdb tests the confirm that gdb works and doesn't hang. These can be used to test toolchain and gdb upgrade to confirm that gdb is still working.

These tests should cover

  • For static prod builds firstly
  • For dynamic dev builds as a close second

daniel.gottlieb@mongodb.com has some context on 

Update:

In a debug=on and opt=off build we want to spin up a whole mongod instance, adding a breakpoint, do some automated gdb stuff, and checking the result.  We can use the existing unit test script with mongod as the input binary and gdb unittest script as parameters.
 



 Comments   
Comment by Max Hirschhorn [ 23/Dec/22 ]

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

Generated at Thu Feb 08 06:18:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.