APR_POOL_DEBUG in apr-util (was: APR_POOL_DEBUG usage question)

dev@ team,

I'm wondering if we could/should remove APR_POOL_DEBUG specifics in
apr-util 1.6.x and 1.7.x, otherwise it's not possible run
non-pool-debug apr-util with pool-debug apr.

Fortunately the only dependency on APR_POOL_DEBUG for apr-util seems
to be the apr_bucket code below.

On Thu, Feb 1, 2024 at 2:38 PM Simon Walter wrote:
>
> I had partial success with '--enable-pool-debug=yes' and
> '--enable-pool-debug=verbose'. Then I ran into something else regarding
> apr-util. I see there are pre-processor conditions based on APR_POOL_DEBUG.
>
> In apr_bucket_alloc_create():
>
> #if APR_POOL_DEBUG
>     /* may be NULL for debug mode. */
>     if (allocator == NULL) {
>         if (apr_allocator_create(&allocator) != APR_SUCCESS) {
>             apr_abortfunc_t fn = apr_pool_abort_get(p);
>             if (fn)
>                 (fn)(APR_ENOMEM);
>             abort();
>         }
>     }
> #endif
>
> Indeed it segfaults in allocator_alloc() because the allocator is null.

Here, if apr was compiled with APR_POOL_DEBUG but apr-util without, it
crashes because the allocator is/remains NULL.

I think this code works without the compile time "#if APR_POOL_DEBUG"
checks because there is no way for apr_pool_allocator_get() to return
NULL besides APR_POOL_DEBUG mode, and of course both apr_pool_t and
apr_bucket_alloc_t are opaque which prevents anyone from playing with
their ->allocator.
It shouldn't either cause too much overhead if running this code for
!APR_POOL_DEBUG.

So don't you think we could/should just remove the "#if
APR_POOL_DEBUG" in buckets/apr_buckets_alloc.c?


Regards;
Yann.