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
