On 15.01.2019 11:48, Stefan Sperling wrote:
> On Tue, Jan 15, 2019 at 11:19:24AM +0100, Stefan Eissing wrote:
>> Stefan: which DEBUG flags are "you" using in production for OpenBSD? I
>> would like to run some h2 tests in exactly that setting...
> We pass --enable-pool-debug=yes to the configure script. That's all.
>> Would OpenBSD be happy with a setting (COMPILE FLAG) that forces
>> the immediate free() by allocators and otherwise skipping the DEBUG
>> flags?
> Yes, I think that would be great. I don't care about the pool debugging
> aspects as much as the benefits we get from direct use of our nalloc/free.
>> Personally, I would like that to be the default behaviour in httpd. The
>> current implementation seems to hinder use of modern address sanitation
>> tools and fuzzing. Something which has proven very valuable in h2.
> Agreed. Note that OpenBSD's malloc/free provide a degree of instrumentation
> similar to address sanitizer. This behaviour is tunable, and the default mode
> is not the most aggressive one. But when applications don't call free when
> they no longer use a chunk of memory, such instrumentation built into the
> system cannot work. See https://man.openbsd.org/malloc#MALLOC_OPTIONS

While I understand all these arguments, I have trouble understanding how
they pertain to APR pools -- since there's no apr_pool_free(), the only
time memory can be returned to the system is during apr_pool_clear() and
apr_pool_destroy(). AFAIR in "production" mode, only the latter will
release memory, whereas apr_pool_clear() will just recycle it. Does
apr_pool_clear() release memory when pool debugging is enabled?

-- Brane

Reply via email to