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

[jandeboevrie]

https://raymii.org/s/software/Logging_all_Cpp_destructors_poor_mans_run-time_tracing.html

[MontagFTB]

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:

https://github.com/wolfpld/tracy

[loeg]

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.

[rqtwteye]

I did this a long time ago with macros. It helped me to find a ton of leaks in a huge video codec codebase.

I still don't understand the hate for the C preprocessor. It enables doing this like this without any overhead. Set a flag and you get constructor/destructor logging and whatever else you want. Don't set it and you get the regular behavior. Zero overhead.

[jonathrg → rqtwteye]

The hate might have to do with it being such a primitive and blunt tool; doing anything moderately complex becomes extremely complicated and fragile.

[tialaramex → jonathrg]

Yeah, this very primitive tool easily creates the programming equivalent of the "iwizard problem".

[You replace straight forwardly "mage" with "wizard" and oops, now your images are "iwizards" and your "magenta" is "wizardnta"]

[jprete]

Address/MemorySanitizer are also meant for this kind of problem. https://github.com/google/sanitizers/wiki/AddressSanitizer https://github.com/google/sanitizers/wiki/MemorySanitizer

Also valgrind, but I'm more familiar with the first two.

[meisel]

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

[neverartful]

I did something similar once but my implementation didn'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.

[meindnoch]

And what was the bug in the end?