Andrew Pinski via Gcc <gcc@gcc.gnu.org> writes: > 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.
BTW, I have a sync for libiberty/ with gnulib. I just haven't posted it yet. But I don't mind rebasing after dmalcolm's work either. > > 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? Yes please! >> >> Thanks >> Dave >>
