httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Event MPM: Spinning on cleanups?
Date Sat, 31 Dec 2005 01:51:33 GMT
I haven't been able to find the bug yet.  As a next step, I'll try using
valgrind on a build with pool debugging enabled.

Brian

On Dec 4, 2005, at 11:14 PM, Paul Querna wrote:

> I finally got around to upgrading to trunk w/ the Event MPM on one  
> of my
> machines. Within a couple hours of starting it, I had a process
> spinning, and consuming 100% CPU.
>
> Backtrace from the spinning thread:
>
> (gdb) thread 6
> [Switching to thread 6 (Thread 0x20450000 (LWP 100189))]#0
> apr_allocator_free
>     (allocator=0x2054ab80, node=0x205a2000) at memory/unix/ 
> apr_pools.c:334
> 334             if (max_free_index != APR_ALLOCATOR_MAX_FREE_UNLIMITED
> (gdb) where
> #0  apr_allocator_free (allocator=0x2054ab80, node=0x205a2000)
>     at memory/unix/apr_pools.c:334
> #1  0x280eb952 in apr_bucket_free (mem=0x0) at
> buckets/apr_buckets_alloc.c:182
> #2  0x280e9915 in heap_bucket_destroy (data=0x205a4090)
>     at buckets/apr_buckets_heap.c:36
> #3  0x280e9a54 in apr_brigade_cleanup (data=0x2059e6b0)
>     at buckets/apr_brigade.c:44
> #4  0x280e9a8b in brigade_cleanup (data=0x2059e6b0) at
> buckets/apr_brigade.c:34
> #5  0x282021bd in run_cleanups (cref=0x2059e028)
>     at memory/unix/apr_pools.c:2044
> #6  0x28202f39 in apr_pool_clear (pool=0x2059e018)
>     at memory/unix/apr_pools.c:689
> #7  0x08081063 in worker_thread (thd=0x81d1660, dummy=0x0) at  
> event.c:682
> #8  0x2820b3e4 in dummy_worker (opaque=0x0) at threadproc/unix/ 
> thread.c:138
> #9  0x2823720b in pthread_create () from /usr/lib/libpthread.so.2
> #10 0x282fa1ef in _ctx_start () from /lib/libc.so.6
>
>
> OS: FreeBSD 6.0-STABLE
> APR: Trunk
> APR-Util: Trunk
> HTTPD: Trunk
>
> Best guess is that we corrupted a bucket brigade by double freeing it,
> or something of that kind.  This is definitely a new behavior since  
> the
> async-write code was merged into trunk.
>
> It is odd that we could of double-free'ed something on the connection
> pool. Maybe it isn't a double-free issue at all...
>
> I'm too tired to debug much of it tonight. Maybe later this week I  
> will
> dig deeper.
>
> -Paul
>


Mime
View raw message