On Mon, Jan 14, 2019 at 11:38:55AM -0600, William A Rowe Jr wrote: > 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.
Well, I am quite happy with it as it is forcing me to fix bugs such as this one which nobody cared to fix for a decade (the quoted comment was written by gstein before SVN 1.0): https://svn.apache.org/r1850651
