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

81–90 of 95 posts

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

#81

Post by anarazel »

simfoo wrote: post #78
anarazel wrote: post #77

Earlier quoted context omitted.

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.

stack_trace allows you to specify a custom allocator, which would protect against a lock held in the allocator (never ran into this in the real world though). You're right about mutex & cv in the general case though

That assumes the specified allocator actually controls all allocations - somewhat doubtful across all platforms as things like dl_iterate_phdr() IIRC allocate memory (and take locks). And there's a lot more to writing signal safe code than not calling malloc. Unless an interface documents to be signal safe you're take better of assuming it is not.

FWIW I've run into malloc self dreadlocks due to rare signals plenty of time :(. In production workloads.

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

#82

Post by leni536 »

otabdeveloper4 wrote: post #79
_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.

There's nothing wrong with the std::regex design as it is the standard. std::regex only sucks because the developers of gcc and clang never bothered to optimize it. (Too much work and they have other stuff to worry about.)

std::regex also depends on locale, which is reason enough to avoid it, regardless of performance.

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

#83

Post by Tempest1981 »

nikbackm wrote: post #80
TeMPOraL wrote: post #12

Earlier quoted context omitted.

First time I hear of VC_EXTRALEAN, always used WIN32_EXTRA_LEAN.

The bad news is that WIN32_EXTRA_LEAN has no effect, you have to define VC_EXTRALEAN if you want to exclude extra stuff from the MFC and VC headers. The good news is also that it has no effect. :) You can verify this for yourself by grepping the Visual Studio headers for VC_EXTRALEAN and WIN32_EXTRA_LEAN.

But it did in 2005?

> VC_EXTRALEAN defines WIN32_LEAN_AND_MEAN and a number of NOservice definitions, such as NOCOMM and NOSOUND.

> https://gamedev.net/forums/topic/367942-win32_lean_and_mean-...

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

#84

Post by plq »

fyrn_ wrote: post #61
plq wrote: post #45

Earlier quoted context omitted.

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

Consider ``` #include ... fmt::print(...); ``` Instead, to save that potential double buffer copy.

Thanks! Still learning my way around the fmt library.

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

#85

Post by therein »

dietrichepp wrote: post #65
npsimons wrote: post #35

Earlier quoted context omitted.

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

Strings in C++ are nice, especially now that we have std::string_view, but is one of the worst pieces of the C++ standard library. - makes localization more difficult, compared to printf (localizing code is beyond awful) - makes thread safety more difficult, compared to printf (it is safe to printf/fprintf from multiple threads, simultaneously, without any extra work) - The operator overloading syntax is bad (my sens…

libfmt is definitely recommended.

About 6-7 years ago back when my employer was running code compiled with gcc-4.4.7 and running it on Linux 2.6.32 boxes even though it was pretty old even back then, it took me a lot of convincing the company to give libfmt a try.

It was such a boost to developer happiness. People were literally overjoyed, writing to me on Slack how much of a pleasure string formatting has become.

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

#86

Post by gpderetta »

anarazel wrote: post #77
simfoo wrote: post #76

Earlier quoted context omitted.

The signal handler just saves the trace and then wakes up another thread which does the reporting. The signaled thread uses only and mutex/cv, all signal-safe as far as I can tell.

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.

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

They are not. Use sem_t for signaling.

edit: also even if they where, the signal handler might wait forever for a mutex owned by the blocked thread.

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

#87

Post by gpderetta »

r2vcap wrote: post #57

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.

I'm afraid you are right. Without async-signal safety, the library is not terribly useful.

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

#88

Post by offices »

dietrichepp wrote: post #65
npsimons wrote: post #35

Earlier quoted context omitted.

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

Strings in C++ are nice, especially now that we have std::string_view, but is one of the worst pieces of the C++ standard library. - makes localization more difficult, compared to printf (localizing code is beyond awful) - makes thread safety more difficult, compared to printf (it is safe to printf/fprintf from multiple threads, simultaneously, without any extra work) - The operator overloading syntax is bad (my sens…

>The operator overloading syntax is bad

In an obnoxious way. The first code someone will see of a new language is often 'hello world'. In C++, 'hello world' is an advertisement for the fact that operator overloading exists.

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

#89

Post by tialaramex »

dietrichepp wrote: post #67
npsimons wrote: post #62

Earlier quoted context omitted.

> The interface is more like printf See, I don't believe that's an improvement. Having used printf in C, I was relieved to be able to "redirect" whatever to a stream, and not care about whether it should be "%d" or "%02f" or even if it was a struct/class. On top of this, treating files as streams, strings as streams, or even extending streams to make a tee-stream[0] all seem clunkier to me with a printf like system.…

> Maybe fmt fixes these problems, I don't know. Yeah, it looks like you did a lot of guesswork in that comment, and a lot of those guesses were inaccurate. Not really trying to be hostile here, but you did acknowledge that you were unfamiliar with std::format. The part that fmtlib / std::format has, which is printf-like, is the idea of having a format string and arguments, rather than having a bunch of separate, piec…

> It would be one thing if were just annoying to use, but it poses problems for localization, thread-safety, accidental misuse through its statefulness, and its operator overloading syntax is bad.

It's Bjarne (Stroustrup)'s pet feature. You'll notice that many expert practitioners of C++ write std::println("Hello, world"); or similar for a canonical C++ 23 Hello World, but Bjarne pointedly still writes it with std::cout and the iostream operator overloads.

Now that Bjarne is back at Columbia teaching, there's a risk he'll infect impressionable young people with this nonsense, COMSW4995 was not an intro class and I suspect Bjarne's jetsetting makes it impractical to teach such a class, so this risk is small but not zero.

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

#90

Post by JonChesterfield »

otabdeveloper4 wrote: post #79
_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.

There's nothing wrong with the std::regex design as it is the standard. std::regex only sucks because the developers of gcc and clang never bothered to optimize it. (Too much work and they have other stuff to worry about.)

"can't be fixed without breaking ABI" sounds plausible for C++.

There's generally not all that much stdc++ specific optimisation stuff in clang. There might be parts of regex that are worth implementing as compiler intrinsics, that seems to be the existing pattern for making bits much faster.

The really heavy lifting you want for regex is to partially evaluate and split them. They're a separate language unto themselves and benefit from being optimised as such. There's nowhere ideal in the clang/llvm pipeline to do that though.

Post reply on HN