I use async logging and, in cases where I cannot debug with debugger attached, I'm forced to update my code to flush logs on each statement. Something like

LOG("something"); LOG_FLUSH();
do_something();
LOG("else"); LOG_FLUSH();
do_something_else();
LOG("done); LOG_FLUSH();

Basically, after each log statement I need to add code to make it flush logs. This way when it crashes I know what was the last log.

What options do I have to "intercept" crashing, so that my async logging thread flushes the logs before allowing "crashing" to continue?

I mainly develop on windows (visual studio) or msys2 (clang, gcc). Msft libc has some hooks for that, like _set_invalid_parameter_handler, there is also SetUnhandledExceptionFilter WinAPI. However, I think most of these should have issues with googletest/boost::test and other testing frameworks which supposedly have to set such handlers.

So, what do async logging libs usually to do avoid losing logs when crashing, and how they handle testing frameworks?

I use async logging and, in cases where I cannot debug with debugger attached, I'm forced to update my code to flush logs on each statement. Something like

LOG("something"); LOG_FLUSH();
do_something();
LOG("else"); LOG_FLUSH();
do_something_else();
LOG("done); LOG_FLUSH();

Basically, after each log statement I need to add code to make it flush logs. This way when it crashes I know what was the last log.

What options do I have to "intercept" crashing, so that my async logging thread flushes the logs before allowing "crashing" to continue?

I mainly develop on windows (visual studio) or msys2 (clang, gcc). Msft libc has some hooks for that, like _set_invalid_parameter_handler, there is also SetUnhandledExceptionFilter WinAPI. However, I think most of these should have issues with googletest/boost::test and other testing frameworks which supposedly have to set such handlers.

So, what do async logging libs usually to do avoid losing logs when crashing, and how they handle testing frameworks?

• c++
• asynchronous
• logging
• googletest

• breakpad for in-process crash handling is good. – 3CxEZiVlQ Commented Mar 13 at 6:01
• 1 I believe that the problem with logger flushing before the crash (but not too often, for performance) is an open topic and it has never been universally solved. Googletest afaik doesn't use any OS specific hooks, it just catches the exceptions by default, but it can be disabled with gtest_catch_exceptions=0, so I guess you can still use your hooks. This answer also suggests using mmap for logging to be able to flush each line without performance cut. – pptaszni Commented Mar 13 at 7:01
• @3CxEZiVlQ something like that, but instead of making minidumps/sending them all I want is to flush log. breakpad is so far overkill for me. – Pavel P Commented Mar 13 at 10:54
• @pptaszni in my case, I think i need flushing no matter what. Imagine: LOG("something"); printf("%s", 123); the logger thread likely won't even have a chance to react to the new log message when the producer thread crashes on the printf right after making the log – Pavel P Commented Mar 13 at 10:56
• Log to a UDP syslog service. No buffering there! – Botje Commented Mar 13 at 19:49

1 Answer 1

So, what do async logging libs usually to do avoid losing logs when crashing

Proceeding with flushing the logs (or with any other activity for that matter) after some thread has crashed is never safe. You never know whether critical memory areas like heap management structures are corrupted and whether standard library functions would work as expected.

A (proprietary) async logging library I've seen didn't even bother intercepting the crash. Instead, it stored queued messages in a kind of circular buffer in memory, and provided a tool that can scan a core dump file, locate that message queue in the dumped process memory, and append those unflushed messages to the log file. In other words, it did the flushing post mortem and didn't interfere with any testing framework.

Such technique was enough for debugging, but obviously it isn't very convenient for the end users.