Re: APR_POOL_DEBUG usage question

On 2024-02-01 14:29, Yann Ylavic wrote:
> On Wed, Jan 31, 2024 at 7:44 PM Simon Walter <[email protected]> wrote:
>>
>> My question about how to debuging should be done. abort() is called on
>> apr_initialize():
>>
>> Program received signal SIGABRT, Aborted.
> 
> Does the attached patch fix the issue with apr_initialize()?
> 

The tests fail in another test. Without much inspection, it's looks like
later in the test (suite? not sure what terminology is being used):

Calling apr_socket_sendfile()...
Headers (3):
        15 bytes (1)
        5 bytes (E)
        80000 bytes (^)
File: 200000 bytes from offset 0
Trailers (3):
        19 bytes
        10 bytes
        90000 bytes
apr_socket_sendfile()->0, sent 370049 bytes
After apr_socket_sendfile(), the kernel file pointer is at offset 0.
client: apr_socket_sendfile() worked as expected!
Waiting for a client to connect...
Processing a client...
server: apr_socket_sendfile() worked as expected!
POOL DEBUG: [32209/139754170767232] DESTROY (       232/    176564/
176564) 0x5595062c42a0 "APR global pool" <memory/unix/apr_pools.c:1741>
0x0 (4/4/0)
POOL DEBUG: [32209/139754170767232] CLEARED (         0/         0/
  232) 0x5595062c4920 "sendfile.c:729" <memory/unix/apr_pools.c:1741>
0x5595062c42a0 (0/30/1)
POOL DEBUG: [32209/139754170767232] CLEARED (         0/         0/
  232) 0x5595062c4880 "apr_initialize" <memory/unix/apr_pools.c:1741>
0x5595062c42a0 (0/0/1)
Programs failed: testmutexscope testall
make[1]: *** [Makefile:163: check] Error 134
make[1]: Leaving directory '/tmp/apr-1.7.4/test'
make: *** [Makefile:129: check] Error 2

The apr_initialize() does not cause abort. So, yes, that does fix those
issues when using '--enable-pool-debug=all'.

I noticed the code in 1.7.0 is a bit different. I applied your patch to
1.7.4. tarball.

Thanks for checking into it and also the hint about apr-util code. If it
is only one 'if', well, I'm not an expert, but it seems minimal.

I haven't had time to start debugging my actual problem, but hopefully soon!

All the best,

Simon