Re: [patch] libstdc++/69945 Add __gnu_cxx::__freeres hook

[Jonathan Wakely <jwakely at redhat dot com>]

On 25/02/16 10:36 +0100, Richard Biener wrote:
> On Wed, Feb 24, 2016 at 7:35 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
> > This adds a new function to libsupc++ which will free the memory still
> > in use by the pool used for allocating exceptions when malloc fails.
> >
> > This is similar to glibc's __libc_freeres, which valgrind (and other
> > tools?) use to tell glibc to deallocate everything before exiting.
> >
> > I initially called it __gnu_cxx::__free_eh_pool() but I figured we
> > might have other memory in use at some later date, and we wouldn't
> > want valgrind to have to start calling a second function, nor make a
> > function called __free_eh_pool() actually free other things.
> >
> > I intentionally *didn't* lock the pool's mutex before freeing it,
> > because this should never be called in a context where multiple
> > threads are still active and accessing the pool.
> >
> > Thoughts?
> >
> > Is the new test a good idea, or will exposing it like that in the
> > testsuite just give users the idea that they can/should be doing the
> > same themselves?
>
> The goal is to lookup the function via dlsym and only call it before
> glibcs freeres (which will probably make free() in-operatable?)

Yes, I believe so (Mark? Ivo?)

Another way to test it would be to use dg-final to run gdb in the
global's destructor and try to call the function from GDB.

> > [ Aside: should the actual pool be created with placement-new to
> > [ ensure it doesn't ever get destroyed?
> > [
> > [   alignas(pool) unsigned char poolbuf[sizeof(pool)];
> > [   pool& emergency_pool = *::new(poolbuf) pool;
>
> Hmm, for pedantic correctness yes I guess.  But it hasn't any destructor,
> it's global (so no CLOBBER / memory re-use issue) and so the destruction
> won't do anything.  Of course it might simply save a global dtor (does it
> even register one?  I don't see one).

It was the CLOBBER that I was thinking about, but I agree we don't
(currently) do that for trivial destructors.

> There is still the missing feature of allowing to size the emergency
> pool using an environment variable (properly securely implemented, of course).

Yes.