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.
