Merge pull request #409 from res2k/leak-docs
Attempt to document leak detection aids
diff --git a/include/vk_mem_alloc.h b/include/vk_mem_alloc.h
index 98553aa..43f87c2 100644
--- a/include/vk_mem_alloc.h
+++ b/include/vk_mem_alloc.h
@@ -77,6 +77,7 @@
- [Memory initialization](@ref debugging_memory_usage_initialization)
- [Margins](@ref debugging_memory_usage_margins)
- [Corruption detection](@ref debugging_memory_usage_corruption_detection)
+ - [Leak detection features](@ref debugging_memory_usage_leak_detection)
- \subpage other_api_interop
- \subpage usage_patterns
- [GPU-only resource](@ref usage_patterns_gpu_only)
@@ -17842,6 +17843,19 @@
`HOST_VISIBLE` and `HOST_COHERENT`.
+\section debugging_memory_usage_leak_detection Leak detection features
+
+At allocation and allocator destruction time VMA checks for unfreed and unmapped blocks using
+`VMA_ASSERT_LEAK()`. This macro defaults to an assertion, triggering a typically fatal error in Debug
+builds, and doing nothing in Release builds. You can provide your own definition of `VMA_ASSERT_LEAK()`
+to change this behavior.
+
+At memory block destruction time VMA lists out all unfreed allocations using the `VMA_LEAK_LOG_FORMAT()`
+macro, which defaults to `VMA_DEBUG_LOG_FORMAT`, which in turn defaults to a no-op.
+If you're having trouble with leaks - for example, the aforementioned assertion triggers, but you don't
+quite know \em why -, overriding this macro to print out the the leaking blocks, combined with assigning
+individual names to allocations using vmaSetAllocationName(), can greatly aid in fixing them.
+
\page other_api_interop Interop with other graphics APIs
VMA provides some features that help with interoperability with other graphics APIs, e.g. OpenGL.
