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

11–20 of 95 posts

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

#11

Post by dataflow »

Night_Thastus wrote: post #7
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?

We've had to use this at my work a couple times. I forget the exact reasoning, but IIRC if you're using including parts of the Win32 API, you get some things that would stomp on C or C++ names, which is bad. Macros like that one prevent loading things you don't want. One example was min and max - Win32 includes those which messes with trying to use std::min and std::max.

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

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

#12

Post by TeMPOraL »

dataflow wrote: post #10
hoten wrote: post #5

Earlier quoted context omitted.

Don't forget `WIN32_EXTRA_LEAN`! Still no idea what that does/did. For those curious about WIN32_LEAN_AND_MEAN - it reduces compile time by not auto-including a number of windows headers: https://devblogs.microsoft.com/oldnewthing/20091130-00/?p=15...

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

First time I hear of VC_EXTRALEAN, always used WIN32_EXTRA_LEAN.

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

#14

Post by kevin_thibedeau »

hoten wrote: post #4
catiopatio wrote: post #2

Reliable in-process crash reporting is exceptionally difficult. The code must be fully async-safe, which means you cannot use . You also cannot acquire mutexes, use any of the standard allocators, etc etc etc.

What's the benefit of in-process crash reporting compared to just using something like crashpad/breakpad? To the extent that in-process crash reporting is even possible... seems the most common class of crashes would be entirely unrecoverable.

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

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

#15

Post by zX41ZdbW »

catiopatio wrote: post #2

Reliable in-process crash reporting is exceptionally difficult. The code must be fully async-safe, which means you cannot use . You also cannot acquire mutexes, use any of the standard allocators, etc etc etc.

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.

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

#16

Post by soulbadguy »

elsamuko wrote: post #13

A question: Would it be possible to pass the stacktrace of the current thread to another, so that the stacktrace would be traceable across threadpools or worker threads?

I am not sure if i understand the question correctly. But 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.

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

#18

Post by mike_hock »

soulbadguy wrote: post #16
elsamuko wrote: post #13

A question: Would it be possible to pass the stacktrace of the current thread to another, so that the stacktrace would be traceable across threadpools or worker threads?

I am not sure if i understand the question correctly. But 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.

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

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

#19

Post by the_svd_doctor »

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.

Can you expand on the problems with regex?

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

#20

Post by verall »

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

Post reply on HN