backward-cpp icon indicating copy to clipboard operation
backward-cpp copied to clipboard

Flushing stdout in the end of signal handling

Open Tomotz opened this issue 2 years ago • 2 comments

Hi, When I'm using the SignalHandling to print stack traces on signals, I sometimes get only a few lines out of the trace, and the app crashes before the whole trace is printed. I think it might be because there is no stdout flush in the end of the prints, and the app crashes with lines in his print buffer. Does that make sense? Is it possible to flush it? Thanks, Tom

Tomotz avatar Feb 10 '22 13:02 Tomotz

It prints to stderr. That's usually not buffered, so it should print directly. And even in the case of buffered output, any \n character should cause the buffer to be flushed. It's very possible that the program is crashing before everything is printed. It could also hang. A lot of the code allocates dynamic memory which could fail in various ways if you had a raised signal (e.g. segmentation fault) in one of the memory allocation routines. If you want reliable error reporting, you'll have to code it yourself using one of the unwind libraries and only use async-signal-safe functions (see: https://man7.org/linux/man-pages/man7/signal-safety.7.html). Apparently, Boost also has boost::stacktrace::safe_dump_to(), so that could work here.

oold avatar Apr 28 '22 21:04 oold

And even in the case of buffered output, any \n character should cause the buffer to be flushed.

This assumption is reasonable for an interactive terminal. But for any other output it depends on the size of the buffer. With that said, when the program terminates, everything should be flushed anyways.

But std::cerr is supposed to flush out everything all the time (https://en.cppreference.com/w/cpp/io/cerr). Making this point moot.

@Tomotz I suggest you add some flush operations to the Printer in "backward.hpp". And see if it helps in your situation. Somebody else proposed to add flushing too in #259 as an example.

It is more likely that you have a bug/memory corruption somewhere.

And as @oold said, if you want a much more reliable error reporting in face of threads, async and signal safety in general, you should write/find/use code that respect this all the way.

bombela avatar Oct 03 '22 20:10 bombela