Detect C++ Memory Leaks with ALSan: Attachable Leak Sanitizer - Bojun Seo - C++Now 2024

[@paulfloyd9258]

Some Valgrind comments. Attaching is possible if the guest is running in Valgrind and you use vgdb. You can request leak reports at any time using client requests (either in instrumented code or vgdb again). Valgrind categorizes pointers that point inside a memory block as 'probable leaks'.

[@szaszm_]

Good talk! I don't fully agree with calling out using raw pointers in general. Instead, my preferred approach is the following: Always consider the nullability and the ownership semantics of each pointer. - A nullable, non-owning pointer is T* (or T* const when possible) - A non-nullable, non-owning pointer is T& (where const works) or gsl::not_null (where you need to mutate the pointer, e.g. data members) - A nullable, owning pointer is std::unique_ptr (const when possible) - A non-nullable, owning pointer is gsl::not_null (const when possible) - When a legacy or C API returns an owning raw pointer, wrap it in gsl::owner or std::unique_ptr on the language or module boundary - When a legacy or C API forces you to use a raw pointer type on an interface for non-nullable parameters, document the assumption with gsl_Expects(ptr) or gsl_ExpectsAudit(ptr) Additionally, always null-check nullable pointer parameters inside functions. And try passing non-nullable, non-owning references/pointers to functions whenever possible, so there is less room for error.

[@paulfloyd9258]

Do you think that this could also be done with DTrace?

[@BojunSeo-tx2df]

It seems like to be possible to be done with DTrace I guess.