[SERVER-42054] Can we get more informative stack traces and core dumps from optimized builds? Created: 02/Jul/19  Updated: 06/Dec/22  Resolved: 29/Jul/19

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

Type: Question Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: DO NOT USE - Backlog - Dev Tools
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Developer Tools
Sprint: Dev Tools 2019-07-29
Participants:

 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?



 Comments   
Comment by Billy Donahue [ 29/Jul/19 ]

I can't think of anything we can do about this. Unassigning myself.

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