https://issues.apache.org/bugzilla/show_bug.cgi?id=48606
--- Comment #3 from Ruediger Pluem <[email protected]> 2010-01-25 08:59:19 CET --- (In reply to comment #0) > In rare situations we face such core dump. > > [Switching to thread 11 (process 12096)]#0 0x00380410 in __kernel_vsyscall () > #0 0x00380410 in __kernel_vsyscall () > #1 0x00163226 in kill () from /lib/libc.so.6 > #2 0x005fcdee in sig_coredump (sig=11) at > /usr/src/debug/httpd-2.2.9.2/phorm/server/mpm_common.c:1239 > #3 <signal handler called> > #4 apr_allocator_free (allocator=0x0, node=0x9ae2a90) at > memory/unix/apr_pools.c:345 > #5 0x007fcd83 in apr_bucket_free (mem=0x9ae2ab8) at > buckets/apr_buckets_alloc.c:191 > #6 0x007fd4cf in heap_bucket_destroy (data=0x9b0b8f0) at > buckets/apr_buckets_heap.c:36 > #7 0x007fe1d2 in apr_brigade_cleanup (data=0x9aed300) at > buckets/apr_brigade.c:44 > #8 0x007fe92a in apr_brigade_destroy (b=0x9aed300) at > buckets/apr_brigade.c:53 > #9 0x005f2405 in ap_core_output_filter (f=0x9ba22d0, b=0x9aed300) at > /usr/src/debug/httpd-2.2.9.2/phorm/server/core_filters.c:882 > #10 0x005feb30 in ap_pass_brigade (next=0x9b0b820, bb=0x9ba7090) at > /usr/src/debug/httpd-2.2.9.2/phorm/server/util_filter.c:526 > #11 0x00602ebb in ap_process_request (r=0x9af7308) at > /usr/src/debug/httpd-2.2.9.2/phorm/modules/http/http_request.c:231 > #12 0x005ffcff in ap_process_http_connection (c=0x9ba1e98) at > /usr/src/debug/httpd-2.2.9.2/phorm/modules/http/http_core.c:190 > #13 0x005fb65d in ap_run_process_connection (c=0x9ba1e98) at > /usr/src/debug/httpd-2.2.9.2/phorm/server/connection.c:43 > #14 0x005fb75c in ap_process_connection (c=0x9ba1e98, csd=0x9ba1ce8) at > /usr/src/debug/httpd-2.2.9.2/phorm/server/connection.c:178 > #15 0x006088cf in worker_thread (thd=0x9ac1ed0, dummy=0x9ac68f8) at > /usr/src/debug/httpd-2.2.9.2/phorm/server/mpm/worker/worker.c:553 > #16 0x00130606 in dummy_worker (opaque=0x9ac1ed0) at > threadproc/unix/thread.c:142 > #17 0x00ecf5ab in start_thread () from /lib/libpthread.so.0 > #18 0x0020bcfe in clone () from /lib/libc.so.6 > > I suppose, the problem is in "proxy_conn_scpool" pool which gets destroyed > prematurely like this: > > #0 ap_proxy_release_connection (proxy_function=0x253507 "HTTP", > conn=0xa596200, s=0x9b25a18) > at /usr/src/debug/httpd-2.2.9.2/phorm/modules/proxy/proxy_util.c:1721 > #1 0x00250905 in ap_proxy_http_cleanup (scheme=0x0, r=<value optimized out>, > backend=0x1) > at /usr/src/debug/httpd-2.2.9.2/phorm/modules/proxy/mod_proxy_http.c:1851 > #2 0x00250bc4 in proxy_http_handler (r=0x9e21e58, worker=0x9b2cb88, > conf=0x9aa53a8, url=0xa2ea530 "/", proxyname=0x0, proxyport=0) > at /usr/src/debug/httpd-2.2.9.2/phorm/modules/proxy/mod_proxy_http.c:1980 > #3 0x00258be6 in proxy_http_handler_wrapper (r=0x9e21e58, worker=0x9b2cb88, > proxy_conf=0x9aa53a8, url=0x9e2328e "http://xxx.xxx.xxx.xxx:3128/", > proxyname=0x0, proxyport=0) at mod_proxysense.cpp:586 > #4 0x05765880 in proxy_run_scheme_handler (r=0x9e21e58, worker=0x9b2cb88, > conf=0x9aa53a8, url=0x9e2328e "http://xxx.xxx.xxx.xxx:3128/", proxyhost=0x0, > proxyport=0) at > /usr/src/debug/httpd-2.2.9.2/phorm/modules/proxy/mod_proxy.c:2511 > #5 0x05769f83 in proxy_handler (r=0x9e21e58) at > /usr/src/debug/httpd-2.2.9.2/phorm/modules/proxy/mod_proxy.c:1016 > > It is destroyed with apr_pool_clear(p) (p is "proxy_conn_pool"). In the > meantime, the brigade was set aside (in ap_core_output_filter()) with backend The buckets that are set aside are not part of a brigade created with the proxy_conn_pool. They have been transfered previously via ap_proxy_buckets_lifetime_transform to a brigade created with the request pool. Pool lifetime management and code in the proxy code is really tricky. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
