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
