On Mon, Jan 14, 2019 at 8:42 AM Stefan Sperling <s...@stsp.name> wrote:

> FYI, the reason APR pool debugging is enabled in production on OpenBSD
> is because, after Heartbleed, OpenBSD decided to force 3rd party software
> to use the operating system's malloc/free implementation instead of custom
> allocators, where possible.
> If there was another way to make APR pools map directly to malloc/free
> I would like to know about it. As far as I undestand, APR pools will
> cache freed memory unless pool debugging is enabled.

Your assessment is correct and by design. The argument by OpenBSD
makes as much sense as attempting to force C construction/destruction
on C++ sources, and OpenBSD users should expect side-effects of this
rather radical change. APR pool Debugging has never been tested for
the same level of robustness as the 'release' pool mechanics, nor have
the many applications which are built upon APR pools. OpenBSD needs
to consider their "port" of these many APR-consuming applications as
independently maintained.

Reply via email to