Re: APR_POOL_DEBUG usage question

2024-02-01 Thread Simon Walter
On 2024-02-01 14:29, Yann Ylavic wrote:
> On Wed, Jan 31, 2024 at 7:44 PM Simon Walter  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)
8 bytes (^)
File: 20 bytes from offset 0
Trailers (3):
19 bytes
10 bytes
9 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" 
0x0 (4/4/0)
POOL DEBUG: [32209/139754170767232] CLEARED ( 0/ 0/
  232) 0x5595062c4920 "sendfile.c:729" 
0x5595062c42a0 (0/30/1)
POOL DEBUG: [32209/139754170767232] CLEARED ( 0/ 0/
  232) 0x5595062c4880 "apr_initialize" 
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


Re: APR_POOL_DEBUG usage question

2024-02-01 Thread Yann Ylavic
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.

Yes, you need to both apr and apr-util consistently with or without
--enable-pool-debug.

Regards;
Yann.


Re: APR_POOL_DEBUG usage question

2024-02-01 Thread Simon Walter



On 2024-02-01 14:21, Yann Ylavic wrote:
> On Thu, Feb 1, 2024 at 1:56 PM Yann Ylavic  wrote:
>>
>> On Wed, Jan 31, 2024 at 7:44 PM Simon Walter  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() != 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


Re: APR_POOL_DEBUG usage question

2024-02-01 Thread Yann Ylavic
On Wed, Jan 31, 2024 at 7:44 PM Simon Walter  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()?

Regards;
Yann.
Index: memory/unix/apr_pools.c
===
--- memory/unix/apr_pools.c	(revision 1913753)
+++ memory/unix/apr_pools.c	(working copy)
@@ -2029,6 +2029,13 @@ APR_DECLARE(apr_status_t) apr_pool_create_ex_debug
 pool->file_line = file_line;
 
 #if APR_HAS_THREADS
+pool->owner = apr_os_thread_current();
+#endif /* APR_HAS_THREADS */
+#ifdef NETWARE
+pool->owner_proc = (apr_os_proc_t)getnlmhandle();
+#endif /* defined(NETWARE) */
+
+#if APR_HAS_THREADS
 if (parent == NULL || parent->allocator != allocator) {
 apr_status_t rv;
 
@@ -2067,13 +2074,6 @@ APR_DECLARE(apr_status_t) apr_pool_create_ex_debug
 pool->ref = NULL;
 }
 
-#if APR_HAS_THREADS
-pool->owner = apr_os_thread_current();
-#endif /* APR_HAS_THREADS */
-#ifdef NETWARE
-pool->owner_proc = (apr_os_proc_t)getnlmhandle();
-#endif /* defined(NETWARE) */
-
 #if (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE)
 apr_pool_log_event(pool, "CREATE", file_line, 1);
 #endif /* (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE) */


Re: APR_POOL_DEBUG usage question

2024-02-01 Thread Yann Ylavic
On Thu, Feb 1, 2024 at 1:56 PM Yann Ylavic  wrote:
>
> On Wed, Jan 31, 2024 at 7:44 PM Simon Walter  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.

>
> Regards,
> Yann.


Re: APR_POOL_DEBUG usage question

2024-02-01 Thread Yann Ylavic
On Wed, Jan 31, 2024 at 7:44 PM Simon Walter  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).


Regards,
Yann.