Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs (opens in new tab)

Do you mean VC_EXTRALEAN? Or is WIN32_EXTRA_LEAN also a thing?

There's NOMINMAX, NOGDI, etc. for that.

not only min, max, other "fun" ones to debug are "near", "far", "small"

I think we had to use that when importing FDI.h (the CAB-extracting part of winapi) to avoid it bringing more legacy cruft.

Well, `std::regex` is literally orders of magnitude slower than other common regex libraries found in JS, Python, Perl, C, etc. It allocates a ton, is poorly implemented, and can never be fixed due to ABI constraints. The entire <regex> subsystem is a mess and should have never been standardized as is.

> What do you use instead [of std::iostream]?

This is what I want to know. Having come from C to C++, iostreams were a big improvement over the "strings" and print functions of C. I even extended a base iostream class to have a "teebuf" logger, that could output to multiple streams and had the standard logging levels.

It's been a while since I last had mastery of C++, but I'd like to hear what is as portable and better than iostreams.

It’s impossible to implement std::regex efficiently due to internal but exposed character handling requirements. To the sibling comments about iostream, thank vzeverovich and everyone that worked on fmt and turning it into std::format (edit: accidentally wrote std::fmt initially), which is vastly superior and not dependent on mutable global state.

1. Historically, std::regex was offered in GCC before it was actually fully implemented. Much hilarity ensued...

2. Some existing implementations have efficiency issues, e.g. performing many allocations.

3. It is claimed (e.g. by Titus Winters) that the ABI of std::regex is problematic, and without breaking it, the implementations cannot be good enough

See these points and others at:

https://www.reddit.com/r/cpp/comments/e16s1m/what_is_wrong_w...

> What's wrong with std::regex?

In my experience, stdlibc++ <regex> is VERY slow, especially on debug builds. We are using g_regex instead, which in turn uses pcre2.

> And iostreams

<iostream> achieves too little with too much code. We instead use:

    std::cout << fmt::format(...);

for simple output, loguru[1] for everything else. I feel like the fmt grammar/mini-language is both nicely extensible and has hit the expressiveness sweet spot -- not too verbose (iostreams) nor too terse (printf).

I also like that fmt has helpers for pointers (fmt::ptr), enums (fmt::underlying) and arrays (fmt::join). It's both easy on the eyes and feels consistent.

[1]: https://github.com/emilk/loguru

IMHO, the printf-style API is superior to the stream based API, because it can be adapted into a logging API that defers string formatting or delegates it to another thread. Overloading by type can be accomplished with printf-style API as well. Cluttering business code with string formatting can be a liability in code that needs to be performant/low latency, which is one of the primary reasons people use C++.

iostreams are not great but are nothing compared to the awkwardness and lack of extensibility of printf style format strings.

iostream is replaced by format.

The implementations are bad and implementers are refusing to fix their own bad implementations so as to not break their own ABI, but that has nothing to do with C++ the standard.

From what I’ve heard, std::regex is notoriously inefficient (lots of memory allocations, no allocator support). But I’ve never used it myself.

1. Can you link to that?

2. Have these changes been offered as patch for libunwind or boost::stacktrace?

It’s not guaranteed to be async-safe. From the C++ proposal (P0881R7):

> Note about signal safety: this proposal does not attempt to provide a signal-safe solution for capturing and decoding stacktraces. Such functionality currently is not implementable on some of the popular platforms.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p08...

[edit] Replying here, because HN is doing its occasional obnoxious rate-limiting of replies:

Signal-safe and async-safe are effectively the same thing, and “async-safe” absolutely isn’t the same thing as “thread-safe”.

A code path that acquires a mutex can be thread-safe; that’s absolutely not async-safe.

If boost implemented a fully async-safe stack unwinder, complete with DWARF expression support, Apple compact unwind encoding support, and all the other features required across platforms, then good for them — but that’s not what <stacktrace> is guaranteed to provide, and such a thing is still not sufficient to implement anything but the most barebones portion of a real crash reporter.

Ease of integration, because having literally anything is typically better than nothing. Honestly Crashpad isn't fun to integrate unless you use a fork like backtrace's (which adds CMake support), which I think doesn't help. I don't know of any alternatives.

A version of Crashpad or something like it with a single turnkey server for database dumps, a one-line "defaults are good enough" integration, would be a real great thing to see.

I guess it is easier to print out some interesting process variables, compared to trying to save and then make sense of dumps etc.

It has value in embedded code where you can stop the world to handle or log fault conditions.

> once collected, stack traces are just regular object that can be passed around thread as other object.

> It's possible that some implementation have references to some stack addresses (like for example the address of a function parameter), in which case you would need to serialize the stack trace before storing them/ moving then another thread.

So which of these two mutually exclusive options is it? As I understand it, that was the question.

The crashing thread might hold a lock in the memory allocator - which could either self deadlock when saving the stack trace (which certainly seems to do memory allocation and thus isn't a-signal safe), or could deadlock with the crash reporting thread which definitely allocates memory all over.

I also quite doubt that std::mutex, and even more so std::condition_variable are guaranteed to be signal safe.