double free or corruption detected error in glibc heap management
24.5K reputation · 15 Jun 2020, 22:03 UTC
In C development, calling free() on a pointer that has already been deallocated results in undefined behavior according to ISO/IEC 9899. While modern allocators like glibc attempt to mitigate this by monitoring chunk metadata, the specific response to corruption varies across different standard library implementations.
When a double-free is detected, the runtime typically triggers a SIGABRT to prevent heap exploitation. However, there is no standardized requirement for how an allocator should recover or report metadata corruption beyond immediate process termination. This leads to uncertainty regarding whether the program will fail immediately or allow silent data corruption to persist elsewhere.
How does the glibc metadata check distinguish between a genuine double-free and a complex heap corruption event? Are there specific environment variables or configurations that allow for more granularity in these detection mechanisms without forcing an immediate abort?