[SERVER-44109] Provide access to raw backtraces and object offsets Created: 18/Oct/19  Updated: 01/Nov/19  Resolved: 01/Nov/19

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

Type: Improvement Priority: Major - P3
Reporter: Benjamin Caimano (Inactive) Assignee: Billy Donahue
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-44091 Attach backtraces to DiagnosticInfo Closed
Duplicate
duplicates SERVER-42406 Provide abstract backtrace support API Closed
Related
is related to SERVER-42406 Provide abstract backtrace support API Closed
Sprint: Dev Tools 2019-11-04
Participants:

 Description   

mongo/util/stacktrace.h provides a function printStackTrace().

I would like an accompanying function to provide the raw backtrace via either:

std::vector<uintptr_t> getStackTrace()

or:

template<typename F> requires Invokable<F, uintptr_t> void iterateStackTrace(F functor)


I would also like a function to convert a uintptr_t instruction address into a tuple object of dynamic object name and file offset:

std::pair<std::string, uintptr_t> getDynamicObjectOffset(uintptr_t instructionAddress)

Actual container or functor types are relatively immaterial to me so long as they do not incur overhead.



 Comments   
Comment by Benjamin Caimano (Inactive) [ 18/Oct/19 ]

Understood. Figured I'd submit this to officially track what I needed.

Comment by Billy Donahue [ 18/Oct/19 ]

Both APIs are part of SERVER-42406, pending. [
https://mongodbcr.appspot.com/512810005]

 

 
 
class Tracer {
    ....
    void print(Context& context, Sink& sink) const;
    size_t backtrace(void** addrs, size_t capacity) const;
    size_t backtraceWithMetadata(void** addrs, AddressMetadata* meta, size_t capacity) const;
    void destroyMetadata(AddressMetadata* meta, size_t size) const;
    int getAddrInfo(void* addr, AddressMetadata* meta) const;
};
 

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