* Andrew Pinski via Gcc: > On Wed, Aug 28, 2024 at 2:37 PM David Malcolm via Gcc <gcc@gcc.gnu.org> wrote: >> >> I've been debugging a use-immediately-after-free bug involving obstacks >> (the bug isn't in trunk; I found it whilst testing one of my patches). >> >> It was only visible as a crash when it happened that the call to >> obstack_free led to the underlying buffer being freed. Most of the >> time, the bug was dormant, since the obstack_free was merely unwinding >> the "high water mark" of allocation within a buffer, and so the >> "obstack_free"d memory was still accessible to the process. >> >> Is there a way to make the obstack code "fussier" e.g. a debug option >> that on obstack_free fills the freed memory with a canary garbage >> value, so that this kind of bug immediately leads to a crash? (probably >> only in a checking build). Similarly, filling obstack memory with >> "not-yet-initialized" etc. I wonder if there's a way to "teach" >> valgrind about obstacks. > > Note obstack upstream is technically glibc.
Did you mean to write gnulib? The copy in glibc is dormant and uses a different ABI (int vs size_t). This situation is far from ideal. Thanks, Florian
