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. Sam had filed a GCC bug report asking adding valgrind notations (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116246) but he found that there is already a bug report opened against gdb for it though: https://sourceware.org/bugzilla/show_bug.cgi?id=30114 . Also libiberty upstream is technically gcc git repo; though most patches are posted to either the GCC mailing list or to gdb and the GCC mailing or to binutils and gcc mailing list. Thanks, Andrew Pinski > > I can try my hand at a patch if people think it's a good idea. It's > part of libiberty, so which mailing list "owns" obstack development? > > Thanks > Dave >
