Show HN: Using C++23 to get proper crash logs in C++ programs • Hacker News Board

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

#51

Post by hoten » Mon, Jul 03, 2023, 10:33 PM UTC

aseipp wrote: post #50

hoten wrote: post #38

Earlier quoted context omitted.

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 `mai…

Thanks for sharing, I'm sure that will come in handy for me some day!

This all feels like a failure of our modern OSes - why must the application layer know how to report on when it crashes? It seems like functionality that the OS should provide! Instead, we're stuck reaching for these random extensions solving the same problem in the same way everywhere - or, if you're lucky, this gets provided by the language framework for "free" to application developers (but not the language developers).

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

#52

Post by _eojb » Mon, Jul 03, 2023, 11:01 PM UTC

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

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 subsystem is a mess and should have never been standardized as is.

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

#53

Post by johannes1234321 » Mon, Jul 03, 2023, 11:17 PM UTC

_eojb wrote: post #52

verall wrote: post #20

Earlier quoted context omitted.

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

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 subsystem is a mess and should have never been standardized as is.

While that is true it can still be a good thing to use on a non-perofrmance critical path instead of adding a dependency on an external library.

Maybe it shouldn't be there and some better thing should be there, but given it exists ... as long as one is aware of alternatives using it is fine.

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

#54

Post by TylerGlaiel » Mon, Jul 03, 2023, 11:26 PM UTC

johannes1234321 wrote: post #53

_eojb wrote: post #52

Earlier quoted context omitted.

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 subsystem is a mess and should have never been standardized as is.

While that is true it can still be a good thing to use on a non-perofrmance critical path instead of adding a dependency on an external library. Maybe it shouldn't be there and some better thing should be there, but given it exists ... as long as one is aware of alternatives using it is fine.

the last time I tried it (it was years ago) std::regex was taking a measurable number of milliseconds to evaluate which is kind of a very long time even outside of performance critical paths.

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

#55

Post by usefulcat » Mon, Jul 03, 2023, 11:27 PM UTC

npsimons wrote: post #35

verall wrote: post #20

Earlier quoted context omitted.

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

> I'd like to hear what is as portable and better than iostreams

Have a look at fmtlib. The interface is more like printf, but type safe and format strings are parsed at compile time. I believe it’s what std::format is based on, which could also be an option for you depending on how recent your compiler/language version is.

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

#56

Post by aseipp » Mon, Jul 03, 2023, 11:28 PM UTC

hoten wrote: post #51

aseipp wrote: post #50

Earlier quoted context omitted.

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 `mai…

Thanks for sharing, I'm sure that will come in handy for me some day! This all feels like a failure of our modern OSes - why must the application layer know how to report on when it crashes? It seems like functionality that the OS should provide! Instead, we're stuck reaching for these random extensions solving the same problem in the same way everywhere - or, if you're lucky, this gets provided by the language frame…

Actually, that's a really a good point. It's also especially weird considering we get lots of debugging support through the OS stack on every system. They have APIs, libraries, tools, etc. But actual crash control, a kind of thing where you want black box recordings after the fact, isn't really a thing anywhere unless you roll it yourself. It's a big shame.

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

#57

Post by r2vcap » Mon, Jul 03, 2023, 11:32 PM UTC

Yet another library feature that will be used by nobody... While having a standard library is good, system programming presents tricky aspects like async-safety that are not adequately addressed. Therefore, considering the challenges involved, I believe it would be better to utilize existing libraries like crashpad to handle such scenarios.

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

#58

Post by verall » Mon, Jul 03, 2023, 11:37 PM UTC

plq wrote: post #45

verall wrote: post #20

Earlier quoted context omitted.

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

fmt looks really nice. Probably worth pulling the dependency in for future projects.

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

#59

Post by zX41ZdbW » Mon, Jul 03, 2023, 11:39 PM UTC

einpoklum wrote: post #32

zX41ZdbW wrote: post #15

Earlier quoted context omitted.

The best way I've found is - patching LLVM's libunwind to make it fully async-signal safe, and sending the stack trace to another thread for symbolization. This is implemented in ClickHouse.

1. Can you link to that? 2. Have these changes been offered as patch for libunwind or boost::stacktrace?

https://github.com/ClickHouse/libunwind/

There were multiple steps:

1. Avoid using malloc/free inside libunwind.

2. Avoid using FDECache that required a mutex.

3. Avoid using dl_iterate_phdr (a mutex inside libc).

4. Protection from dereferencing wrong pointers due to incorrect unwind tables.

Most of the changes were integrated to libunwind, but not everything. Example: https://bugs.llvm.org/show_bug.cgi?id=48186

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

#60

Post by ninepoints » Mon, Jul 03, 2023, 11:52 PM UTC

johannes1234321 wrote: post #53

_eojb wrote: post #52

Earlier quoted context omitted.

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 subsystem is a mess and should have never been standardized as is.

While that is true it can still be a good thing to use on a non-perofrmance critical path instead of adding a dependency on an external library. Maybe it shouldn't be there and some better thing should be there, but given it exists ... as long as one is aware of alternatives using it is fine.

There's "not fast but usable enough" of course, but I would never ship std::regex code on any user facing software. Forget realtime, std::regex fails to be interactive in examples where other libraries resolve quickly.