[SERVER-35503] Backtrace document should include buildInfo Created: 08/Jun/18  Updated: 23/Jul/18  Resolved: 01/Jul/18

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Andrew Morrow (Inactive)
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

POSIX


Issue Links:
Related
related to SERVER-13944 Provide richer unwind information in ... Closed
Participants:

 Description   

Backtrace documents include info about the environment that the process is running in:

{
    "backtrace" : [
        ...
    ],
    "processInfo" : {
        "mongodbVersion" : "4.0.0-rc4",
        "gitVersion" : "ee1028693fe28bbfbd4dbc4030aed14493e0b2fb",
        "compiledModules" : [ ],
        "uname" : {
            "sysname" : "Linux",
            "release" : "4.13.0-32-generic",
            "version" : "#35~16.04.1-Ubuntu SMP Thu Jan 25 10:13:43 UTC 2018",
            "machine" : "x86_64"
        },
        "somap" : [
            ...
        ]
    }
}

Before you can interpret the addresses in the stacktrace you need to get the correct buildvariant debugsymbols file, which for released versions requires knowing the distmod and distarch. At present distmod has to be figured out heuristically from processInfo.uname.version (or some other out of band way), and distarch will usually (but maybe not always) be the same as processInfo.uname.machine. It would be much better if these values were already present in the backtrace document. We could add just fields for distmod/distarch, or maybe the whole buildEnvironment subdoc (from the buildInfo command), though this would add a fair bit to already verbose output.

> db.serverBuildInfo()
{
        "version" : "4.0.0-rc4",
        "gitVersion" : "ee1028693fe28bbfbd4dbc4030aed14493e0b2fb",
        "modules" : [ ],
        ...
        "buildEnvironment" : {
                "distmod" : "ubuntu1604",
                "distarch" : "x86_64",
                "cc" : "/opt/mongodbtoolchain/v2/bin/gcc: gcc (GCC) 5.4.0",
                "ccflags" : "-fno-omit-frame-pointer -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -O2 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-but-set-variable -Wno-missing-braces -fstack-protector-strong -fno-builtin-memcmp",
                "cxx" : "/opt/mongodbtoolchain/v2/bin/g++: g++ (GCC) 5.4.0",
                "cxxflags" : "-Woverloaded-virtual -Wno-maybe-uninitialized -std=c++14",
                "linkflags" : "-pthread -Wl,-z,now -rdynamic -Wl,--fatal-warnings -fstack-protector-strong -fuse-ld=gold -Wl,--build-id -Wl,--hash-style=gnu -Wl,-z,noexecstack -Wl,--warn-execstack -Wl,-z,relro",
                "target_arch" : "x86_64",
                "target_os" : "linux"
        },
        ...
        "ok" : 1
}



 Comments   
Comment by Andrew Morrow (Inactive) [ 01/Jul/18 ]

Closing as WF. A buildid database is a better way to handle this, and the buildId is already in the backtrace.

Comment by Andy Schwerin [ 19/Jun/18 ]

The build-id is in the back trace, yes.

On Tue, Jun 19, 2018, 12:19 PM Andrew Morrow (JIRA) <jira@mongodb.org>

Comment by Andrew Morrow (Inactive) [ 19/Jun/18 ]

And isn't the buildid info already in the backtrace?

Comment by Andrew Morrow (Inactive) [ 19/Jun/18 ]

I'm opposed to putting distmod and distarch in anywhere - they don't have any canonical meaning, and are simply passthroughs of values provided either on the command line or from other places in the system. I'd not like us to bake their presence or current values into anything more downstream if we can help it.

Comment by Andy Schwerin [ 08/Jun/18 ]

This is a reasonable suggestion, but what we should really be doing is indexing the debug symbols by build-id instead of by distarch. That solution would be foolproof. cristopher.stauffer .

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