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.
