Re: APR_POOL_DEBUG usage question

On 2024-02-01 14:21, Yann Ylavic wrote:
> On Thu, Feb 1, 2024 at 1:56 PM Yann Ylavic <[email protected]> wrote:
>>
>> On Wed, Jan 31, 2024 at 7:44 PM Simon Walter <[email protected]> wrote:
>>>
>>> Should I use '--enable-pool-debug=yes' or '--enable-pool-debug=verbose'?
>>
>> I'd suggest using simple --enable-pool-debug[=yes] and ASan (Address
>> Sanitizer, i.e. "-fsanitize=address -fno-sanitize-recover=address" in
>> $CFLAGS).
> 
> I mean, ASan for compiling the APR eventually, but it should be used
> to compile your program too for a full leaks/use-after-free coverage.

Thanks Yann!

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.

I'll try with just the $CFLAGS you suggested, Yann, and see if I can
find the double free without APR_POOL_DEBUG code. Because building
apr-utils will not be as easy apr. I've been using debian libs and -dev
pkgs, which up until now have been all I needed. Time to dive deeper I
suppose.

Thanks again,

Simon