On Wed, Feb 24, 2016 at 7:35 PM, Jonathan Wakely <jwak...@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?) > > [ 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). There is still the missing feature of allowing to size the emergency pool using an environment variable (properly securely implemented, of course). Richard. > >
