* Andrew Pinski via Gcc:
> On Wed, Aug 28, 2024 at 2:37 PM David Malcolm via Gcc 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
