Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-42054

Can we get more informative stack traces and core dumps from optimized builds?

    XMLWordPrintable

    Details

    • Type: Question
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Internal Code
    • Labels:
      None
    • Sprint:
      Dev Tools 2019-07-29

      Description

      This ticket is the result of a Replication Team meeting where we considered what costs us time debugging Evergreen test failures. One time-consuming scenario is when a flaky test fails, giving us a core dump and stack trace, but only on an optimized build. This could happen because the debug build has different timings, or just bad luck.

      The stack trace for an optimized build omits some parameters:

      0x0000564b0908f502 in mongo::Lock::GlobalLock::GlobalLock (this=0x7fb704ea45f8, opCtx=<optimized out>, lockMode=<optimized out>, deadline=..., behavior=<optimized out>) at src/mongo/db/concurrency/d_concurrency.cpp:139
      

      And when we load the core dump in GDB, many local variables and parameters are inaccessible.

      Obviously, a release build must be less debuggable than a debug build, but is there anything we can do to get better stack traces and more informative core dumps from release builds than we do today, without making the binary bigger or slower?

        Attachments

          Activity

            People

            Assignee:
            backlog-server-devtools DO NOT USE - Backlog - Dev Tools
            Reporter:
            jesse A. Jesse Jiryu Davis
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: