apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From E Holyat <ehol...@yahoo.com>
Subject Re: apr_allocator_destroy infinite loop
Date Wed, 03 Aug 2005 04:17:45 GMT
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 <striker@apache.org> 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 
Mime
View raw message