jeremy-rifkin
commented
9 months ago Hi @VelocityRa, I see how that trace can be misleading and that's definitely something I'd like to address.
Defining what it means for a trace to be "full" or not is slightly unclear because it's not uncommon for some information to be missing (e.g. libraries might not be built with debug symbols) but the rest of the information should be accurate and hopefully useful.
Additionally, it's often not known whether there will be useful information until after attempting to resolve the trace.
I think ideally in this situation even when symbols aren't present for one object the trace should have blank or partially blank frames with as much information as was possible to extract, for example
Stack trace (most recent call first):
#0 0x00000001034fd788 at /Users/rifkin/foo/cpptrace/build/test
#1 0x00000001034fd758 at /Users/rifkin/foo/cpptrace/build/test
#2 0x00000001034fd728 at /Users/rifkin/foo/cpptrace/build/test
#3 0x00000001034fd908 in buzz() at /Users/rifkin/foo/cpptrace/build/bar.cpp:4:2
#4 0x00000001034fd978 in biz() at /Users/rifkin/foo/cpptrace/build/bar.cpp:8:2
#5 0x00000001034fd988 in bar() at /Users/rifkin/foo/cpptrace/build/bar.cpp:12:2
#6 0x00000001034fd8d8 at /Users/rifkin/foo/cpptrace/build/test
#7 0x00000001034fd8e8 at /Users/rifkin/foo/cpptrace/build/test
```or even
```c
Stack trace (most recent call first):
#0 0x00000001034fd788
#1 0x00000001034fd758
#2 0x00000001034fd728
#3 0x00000001034fd908 in buzz() at /Users/rifkin/foo/cpptrace/build/bar.cpp:4:2
#4 0x00000001034fd978 in biz() at /Users/rifkin/foo/cpptrace/build/bar.cpp:8:2
#5 0x00000001034fd988 in bar() at /Users/rifkin/foo/cpptrace/build/bar.cpp:12:2
#6 0x00000001034fd8d8
#7 0x00000001034fd8e8Personally I'd lean more towards providing as much information as possible as opposed to conditionally disabling stacktrace generation, as long as what is there is accurate. Does that work for your use case?
I don't think frames should blindly resolve to the closest symbol if their actual entry isn't there but I can double check the logic. Ideally it is returning an error under the hood if a symbol isn't found.
It would be helpful to know a little more about how you are compiling and what's going on here. Are you using msvc? Are optimizations on?
I'm surprised to not see a main entry, usually the calls should look something like RtlUserThreadStart -> BaseThreadInitThunk -> mainCRTStartup -> __scrt_common_main -> __scrt_common_main_seh -> invoke_main -> main or RtlUserThreadStart -> BaseThreadInitThunk -> mainCRTStartup -> __tmainCRTStartup -> main.
I'm definitely surprised to see a SM2KeyExchange entry from BaseThreadInitThunk. At the moment either some bug with omitting frames when an error occurs or your theory about the resolver picking the closest symbol seems most plausible.
VelocityRa
I have inherited
cpptrace::lazy_exceptionto make my own type with some niceties, and I throw this exception type in my codebase.cpptrace adds a stacktrace in the
.what()string as expected, but if symbols (in my case a.pdbnext to the.exe) are not available, it results in bogus stacktraces like so:These appear to be func names from libtpms, a library that I'm using that presumably embeds dwarf symbols. The exception does not originate there however, presumably it picks them up because there are no other symbols available (so it picks the closest before the exception instruction pointers).
Is there a solution? Perhaps simply a way to detect whether 'full' symbols are available, so I can make my class not fetch the stacktrace if so? Or perhaps simply whether the
dbghelpbackend is available / was used for a stacktrace?Thanks for the awesome library!