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

Reply via email to