Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Using C++23 to get proper crash logs in C++ programs

github.com

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#41

Post by scatters »

verall wrote: post #20
zX41ZdbW wrote: post #17

There are parts of C++ standard library that no one should ever use. The examples are: regex, iostreams, locale... My main concern - this can also become such a dead weight.

What's wrong with std::regex? Seems to work fine for me. And iostreams - they're not great. Bad programming UI, poor performance, etc. Issues abound. But should you never use them? What do you use instead? *printf methods have lots of issues too. And so does depending on Boost::format. And so does writing your own Logger/wrapping code (which is what everyone does AFAICT). locale is bad though

iostream is replaced by format.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#43

Post by einpoklum »

catiopatio wrote: post #33
einpoklum wrote: post #30

Earlier quoted context omitted.

What is async-unsafe in using ` `? As for not using standard allocators - not a problem, just have a fixed area set aside as a buffer for crash reporting. Yes, it might not fit an extremely long report, but it's not that much of an issue.

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 r…

1. signal-safe and async-safe/thread-safe is not quite the same thing, but fair enough.

2. The boost::stacktrace library (on which the standardization was mostly based IIANM) has a `safe_dump_to()` function for these cases.

See here: https://github.com/boostorg/stacktrace/blob/develop/include/...

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#44

Post by evmar »

The code:

    //a decent amount of this was copied/modified from backward.cpp (https://github.com/bombela/backward-cpp)
The license on the other side of that link:

    The above copyright notice and this permission notice shall be included in all
    copies or substantial portions of the Software.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#45

Post by plq »

verall wrote: post #20
zX41ZdbW wrote: post #17

There are parts of C++ standard library that no one should ever use. The examples are: regex, iostreams, locale... My main concern - this can also become such a dead weight.

What's wrong with std::regex? Seems to work fine for me. And iostreams - they're not great. Bad programming UI, poor performance, etc. Issues abound. But should you never use them? What do you use instead? *printf methods have lots of issues too. And so does depending on Boost::format. And so does writing your own Logger/wrapping code (which is what everyone does AFAICT). locale is bad though

> What's wrong with std::regex?

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

> And iostreams

achieves too little with too much code. We instead use:

    std::cout
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

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#46

Post by gpderetta »

elsamuko wrote: post #40
gpderetta wrote: post #34

Earlier quoted context omitted.

Ah. I guess you can capture the stack trace at task creation point, then stitch together a new stack trace by replacing the generic common prefix of your worker thread trace with the task creation one. But you can't use the basic_stacktrace container itself as it is immutable and not constructibe from a range, so you have to roll your own. You should be able to use the stacktrace_entries though. Most importantly, I e…

Exactly this. I didn't try this, and I suppose that some low level pointer rewriting would be necessary to do this. I'm not sure if it's expensive though, maybe you can replace the pointers without resolving the stacktrace.

The problem is that to get the stacktrace of the task creation you have to traverse the stack at that point in time. You can't really do it later. And stack traversal using DWARF unwind info, for example, is neither cheap nor simple. You might have better luck if you compile with frame pointer though.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#47

Post by mlhpdx »

I may be wrong, but as I recall it is good form to chain exception filter calls by making note of the return from `SetUnhandledExceptionFilter`. For example, if I want to use `` and do copy-on-write using memory protection in the same program.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#48

Post by LexiMax »

rightbyte wrote: post #3

This is my favorite macro: "#define WIN32_LEAN_AND_MEAN" Why is it that even though Github or what ever has cutsie unicorns (or whatever it is) as error messages it feels fake and contrived while this define just feels like some random dude at MS naming it before going off to write Solitaire?

I've always been a fan of _CRT_SECURE_NO_WARNINGS, personally.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#49

Post by londons_explore »

evmar wrote: post #44

The code: //a decent amount of this was copied/modified from backward.cpp (https://github.com/bombela/backward-cpp) The license on the other side of that link: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

This is only an issue if the original author chooses to enforce. You don't know - this code may have been given special permission to omit the notice by the original author. It isn't up to random joe to find copyrights they think have been violated.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#50

Post by aseipp »

hoten wrote: post #38
aseipp wrote: post #29

Earlier quoted context omitted.

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 gr…

I found Sentry's crash reporting (which uses crashpad) simple enough to configure into an existing CMake build within an afternoon. Building Sentry/crashpad from source in a few lines of CMake: https://github.com/ArmageddonGames/ZQuestClassic/commit/3471... And a few lines in the main function: https://github.com/ArmageddonGames/ZQuestClassic/commit/3471...

Neat, I didn't know Sentry also had a good fork, I haven't tried it! But in contrast, here's an in-process fault library that I whipped up (from forking Phusion Passenger) about 10 years ago that I still reach for sometimes, which is surprisingly robust to most of the original complaints about async safety, but still not perfect: https://github.com/thoughtpolice/libfault

You add one C file and 6 lines of code in `main()`, and you can do this in pretty much any programming language with a tiny extra bit of glue. It takes 3 minutes to do this in any C/C++ codebase of mine. It is build system agnostic and works immediately, with zero outside deps. It's something, and that's better than nothing, in practice. So people reach for that. I reach for it. And not just because I wrote it.

I want to be clear: Crashpad is 10000x better than mine in every way, except this one way. And I really wish it wasn't. To add onto this, I really don't like CMake for example, so this problem isn't just a "well I like my thing." I want something that will also work in my Java programs, or Rust programs, for instance! Sometimes they crash too. I don't need to add any dependencies except like 2 or 3 C function calls, which almost every langauge supports with a native FFI out of the box. The friction is extremely low.

I'm reminded of something Yann Collet once said about the design of zstd, and getting people to adopt new compression technology. If you make a compressor and it's better than an alternative in one or more dimensions, but worse in another (size, decompressor speed), then friction is actually significantly increased by that one failure. But if you make it better in every dimension -- so it gives an equal ratio and compression and decompression are always better than alternatives -- the friction is eliminated and people will just reach for it. Even though you only did worse in one spot, people find ways to make it matter. It really makes people think twice. But if it's always better, in every way, then using and reaching for it is just instinctive -- it replaces the old thing entirely.

So that's what I really wish we had here. I think that's what you would need to see a lot better crash handling and reporting become more widely used. There needs to be a version of Crashpad, or any robust out of process crash collector, that you can just drop into any language and any build system with a little C glue (or Rust! Sure! Whatever!) in 5 minutes and it should have a crash database server and crash handler process which should instantly work for most uses.

Post reply on HN