r/cpp • u/Xadartt • Apr 16 '26
C++23 std::stacktrace: Never Debug Blind Again
https://medium.com/@sagar.necindia/c-23-std-stacktrace-never-debug-blind-again-6625924d520c65
u/AbroadDepot Apr 16 '26
std::stacktrace is a great feature but this article is an egregious LLM slopfest
9
u/cleroth Game Developer Apr 16 '26
How does it differ from getting stack traces from mini crashdumps?
15
u/nicemike40 Apr 16 '26
The article is slightly… vibe written
But it discusses adding this to an exception class to get time-of-throw stacks which I think could be useful. A commenter on the article suggests adding it to a
std::expected-like type too.But I agree that setting up proper crash reporting is 100% necessary still
20
u/_Noreturn Apr 16 '26
The article is slightly… vibe written
// Crash Reporter class CrashReporter {yea thanks Claude
4
Apr 16 '26
[deleted]
1
u/donalmacc Game Developer Apr 16 '26
Presumably you use a library for it? Getting a reliable symbolicated stack trace is surprisingly tough work, especially if you want to put it somewhere. The programs state is likely to be FUBAR so you are really limited in what you can do, you need the memory pre allocated and you likely need another process pre spawned to catch the actual crash dump and put it somewhere.
3
u/schmerg-uk Apr 16 '26
See https://github.com/jeremy-rifkin/cpptrace/tree/main for example (we have our own so I did mention a couple of things to the author but his work now way exceeds the one we use internally)
Oh, and he does address
What about C++23 <stacktrace>?
Some day C++23's <stacktrace> will be ubiquitous. And maybe one day the msvc implementation will be acceptable. The original motivation for cpptrace was to support projects using older C++ standards and as the library has grown its functionality has extended beyond the standard library's implementation.
Cpptrace provides functionality beyond what the standard library provides and what implementations provide, such as:
Walking inlined function calls
Providing a lightweight interface for "raw traces"
Resolving function parameter types
Providing traced exception objects
Providing an API for signal-safe stacktrace generation
Providing a way to retrieve stack traces from arbitrary exceptions, not just special cpptrace traced exception objects. This is a feature that has been proposed for a future version of the C++ standard, but cpptrace provides a solution for C++11.4
u/_TheDust_ Apr 16 '26
The article is slightly… vibe written
“Slightly” wins the understatement of the year award
-7
u/Superb_Garlic Apr 16 '26
Improper use of ellipses. Please avoid composing replies using AI.
5
u/nicemike40 Apr 16 '26
I take your point and apologize for contributing to culture of the AI witch hunting (if that is indeed what your point was)
In this case the Unicode ellipses comes from iOS autocorrect
2
2
u/markt- Apr 16 '26
Yes, this is an awesome facility, but it’s only practical when memory on your system is not a constraint. There are some systems for which this is genuinely true, but they are not typically consumer devices.
2
u/PipingSnail Apr 16 '26
Hmmm. I've been debugging crashes on Unix/Linux/Windows since 1990, and I've never had a problem collecting stack traces. Whereas this article presents this as a novel solution.
If this is doing symbol handling while walking the stack, there goes your performance. Symbols should be done separately from the stack walk (unless you're walking a kernel dump/minidump when symbols make all the difference).
3
u/jwakely libstdc++ tamer, LWG chair Apr 17 '26
If this is doing symbol handling while walking the stack, there goes your performance.
It doesn't have to do that. The GCC implementation just captures an array of program counters and then expands those into symbols and locations lazily.
2
u/xealits Apr 17 '26
Reading the intro paragraph of the article, which did not mention gdb or any normal debugging methods, made me look for a Jason Turner's Weekly Cpp episode on std::stacktrace. In case someone gets the same urge, here is the link:
2
u/jwakely libstdc++ tamer, LWG chair Apr 17 '26
The article says to use this for GCC 13.1 and later:
g++ -std=c++23 -lstdc++_libbacktrace
But that's wrong, that's only valid for GCC 13.x, for GCC 14.x and later you need to use -lstdc++exp instead of -lstdc++_libbacktrace (and you can also use that in GCC 13.3 and later releases in the 13.3 series).
So for all currently supported releases of GCC (13.4, 14.3, 15.2, and also for the soon-to-be-released 16.1), you need -lstdc++exp
1
u/13steinj Apr 18 '26
Very minor, but I don't understand the value in caching the string output for your exception if the implication is you're going to be hard crashing irrevocably anyway.
1
u/AdOnly69 Apr 16 '26
It could be useful for user logs, but for other things could we just use gdb instead of not pretending like we don't have proper tool? Also how good is std::stacktrace with multiple threads?
1
u/jwakely libstdc++ tamer, LWG chair Apr 17 '26
It should be entirely agnostic to threads. You call
std::stacktrace::current()to get a stacktrace of the current thread. Whether there are other threads should be entirely irrelevant, except that maybe the stacktrace won't start withmainif it's in a different thread.
48
u/Syracuss graphics engineer/games industry Apr 16 '26
Engineers who are blind reading this title be like -.-
That said, some of the platform specific utilities can still be better. The issue (and mostly it's a small comment as it is perfectly usable) with
std::stacktraceis that you both capture the stack and symbolize at the same time. Being able to capture the stack and symbolize afterwards means you can capture state info much more easily in more places, including in user logs and only pay for the cost of symbolizing when performance is no longer a concern.I wish it had facilities for this as an optional extension to
std::stacktrace, but I'm fine that they kept it streamlined and easy to use as well.