Re: apr_allocator_destroy infinite loop

[E Holyat]

allocator_alloc

 

Try moving the mutex outside of the

if ... else if ... statement

 

Index: memory/unix/apr_pools.c
===================================================================
--- memory/unix/apr_pools.c     (revision 226348)
+++ memory/unix/apr_pools.c     (working copy)
@@ -193,11 +193,11 @@
     /* First see if there are any nodes in the area we know
      * our node will fit into.
      */
-    if (index <= allocator->max_index) {
 #if APR_HAS_THREADS
         if (allocator->mutex)
             apr_thread_mutex_lock(allocator->mutex);
 #endif /* APR_HAS_THREADS */
+    if (index <= allocator->max_index) {

         /* Walk the free list to see if there are
          * any nodes on it of the requested size
@@ -248,20 +248,12 @@
             return node;
         }

-#if APR_HAS_THREADS
-        if (allocator->mutex)
-            apr_thread_mutex_unlock(allocator->mutex);
-#endif /* APR_HAS_THREADS */
     }

     /* If we found nothing, seek the sink (at index 0), if
      * it is not empty.
      */
     else if (allocator->free[0]) {
-#if APR_HAS_THREADS
-        if (allocator->mutex)
-            apr_thread_mutex_lock(allocator->mutex);
-#endif /* APR_HAS_THREADS */

         /* Walk the free list to see if there are
          * any nodes on it of the requested size
@@ -288,11 +280,12 @@
             return node;
         }

+    }
+
 #if APR_HAS_THREADS
         if (allocator->mutex)
             apr_thread_mutex_unlock(allocator->mutex);
 #endif /* APR_HAS_THREADS */
-    }

     /* If we haven't got a suitable node, malloc a new one
      * and initialize it.

Sander Striker <[EMAIL PROTECTED]> wrote:

Cliff Woolley wrote:
> On Mon, 25 Jul 2005, Wilson, Brian A wrote:
>
>
>>I'm trying to track down an error when closing a program using apr. In
>>the jxta-c shell it calls apr_terminate upon exit but it ends up in an
>>infinite while loop in apr_allocator_destroy. I've traced it down to a
>>point where the while loop is being called on a circular pair of nodes.
>>Such that A->next = B and B->next = A. I've tried adding an escape
>>check to exit if it gets to that situation but that leaves large amounts
>>of memory lost. Any ideas on what could be the cause and possible
>>solutions?
>
>
> I'm guessing the best way to attack this is to figure out where the loop
> came from in the first place rather than simply detecting it and
> compensating after the fact. There are a number of pool debugging options
> you can enable that might help here... CC: Sander to comment on which ones
> would be most useful in this particular scenario.

First would be to compile with --enable-pool-debug=yes. Or even:
--enable-pool-debug="lifetime owner". Your application will abort()
when something is fishy.

FYI, possible options are:
--enable-pool-debug[[=yes|no|verbose|verbose-alloc|lifetime|owner|all]]

I don't think you need verbose-alloc to track this down.

In case you suspect corruption because of reuse of freed memory (cleared/destroyed
pool), you could try with simply --enable-pool-debug=yes, and then using
a tool like valgrind to figure out where the problem is.

If you know what pools are causing the trouble, or when you've tagged
your pools (see: apr_pool_tag()), you could try and see if you can figure
it out by looking at the verbose output generated when compiling with
--enable-pool-debug=verbose. With this option you can see when a pool
is created, cleared and/or destroyed, including information about the
parent pool, number of allocations and tag.

HTH,

Sander

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com