Logging all C++ destructors, poor mans run-time tracing

But what was the shutdown bug you were trying to identify? Was this destructor logging actually useful? The article teases the problem and provides detailed instructions for reproducing the logging, but doesn't actually describe solving the problem.

Address&#x2F;MemorySanitizer are also meant for this kind of problem. <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;sanitizers&#x2F;wiki&#x2F;AddressSanitizer">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;sanitizers&#x2F;wiki&#x2F;AddressSanitizer</a> <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;sanitizers&#x2F;wiki&#x2F;MemorySanitizer">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;sanitizers&#x2F;wiki&#x2F;MemorySanitizer</a><p>Also valgrind, but I&#x27;m more familiar with the first two.

One of my favorite hacky workarounds is to simply call _exit(0) for an immediate exit without running destructors. Most of the time, the destructors are just freeing memory that will be reclaimed by the OS anyways so they are not worth running if you know the program is exiting. And even if the destructor does more than just freeing memory, maybe the work it&#x27;s doing isn&#x27;t needed if you know the process is ending soon: maybe it&#x27;s joining threads or releasing mutexes or deleting timers.<p>You will find that in a typical C++ codebase, the destructors that do useful things (say, flushing useful buffers and closing files etc) are much fewer.

I did this a long time ago with macros. It helped me to find a ton of leaks in a huge video codec codebase.<p>I still don&#x27;t understand the hate for the C preprocessor. It enables doing this like this without any overhead. Set a flag and you get constructor&#x2F;destructor logging and whatever else you want. Don&#x27;t set it and you get the regular behavior. Zero overhead.

I consider Tracy the state of the art for profiling C++ applications. It’s straightforward to integrate, toggle, gather data, analyze, and respond. It’s also open source, but rivals any product you’d have to pay for:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;wolfpld&#x2F;tracy">https:&#x2F;&#x2F;github.com&#x2F;wolfpld&#x2F;tracy</a>

I did something similar once but my implementation didn&#x27;t rely on any compiler features. I made tracing macros for constructors, destructors, and regular c++ methods. If the tracing was turned on in the macros, the information given to the macro (class name, method name, etc.) would be passed to the tracing manager. The tracing manager would serialize to a string and send it through a TCP socket. I also wrote a GUI tracing monitor that would listen on a socket for tracing messages and then display the trace messages received (including counts by class and method). The tracing monitor had filters to tweak. It was a nice tool to have and was very instrumental in finding memory leaks and obscure crashes. This was back in the late 1990s or early 2000s.

Just spent three days of debugging hell getting my app to shut down gracefully, so that it gracefully turns off all the things that it asynchronously turned on without performing use-after deletes). I can sympathise with that.

Don&#x27;t know why the link to the GCC runtime instrumentation docs points to the internet archive. The direct link is <a href="https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gcc&#x2F;Instrumentation-Options.html" rel="nofollow">https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gcc&#x2F;Instrumentation-Options.h...</a>

And what was the bug in the end?

I’d say address sanitizer is a better starting point, and likely to show memory issues faster than this

Too bad, it doesn&#x27;t work like this on macOS.