httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Edmundsson <ni...@acc.umu.se>
Subject httpd 2.2.8 + mod_cache segfaults
Date Wed, 20 Feb 2008 10:39:44 GMT

Hi all!

Getting a few cycles I thought I should do an easy migration to httpd 
2.2.8, but it seems that the thing is dumping core on me...

Are anyone else using httpd 2.2.8 together with mod_cache seeing this? 
At the moment I'm not sure where the problem is. Our mod_disk_cache 
patches are unchanged from 2.2.6 and my patch for mod_cache.c is the 
same (the relaxupdates feature, and it's not enabled in config), so 
I'm suspecting something changed between httpd 2.2.6 and 2.2.8 that 
makes it fall apart on me.

Anyone seen something similar? Any hints on where to dig?

The request is a regular GET, I didn't find any obvious NULL-pointers 
in the variables that the compiler optimizer hadn't removed.

All backtraces I've looked at looks similar to this:
---------------------8<-----------------------------
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d0cca6 in kill () from /lib/tls/i686/cmov/libc.so.6
#2  0x08081add in sig_coredump (sig=4671) at mpm_common.c:1235
#3  <signal handler called>
#4  0x00000000 in ?? ()
#5  0x0808a103 in ap_byterange_filter (f=0x832c370, bb=0x832d440)
     at byterange_filter.c:271
#6  0xb7cab180 in cache_out_filter (f=0x832d428, bb=0x832d440)
     at mod_cache.c:298
#7  0xb7cac60c in cache_url_handler (r=0x832b630, lookup=0) at mod_cache.c:245
#8  0x08079280 in ap_run_quick_handler (r=0x832b630, lookup=0) at config.c:160
#9  0x08087099 in ap_process_request (r=0x832b630) at http_request.c:254
#10 0x0808447b in ap_process_http_connection (c=0x831f7b8) at http_core.c:190
#11 0x08080549 in ap_run_process_connection (c=0x831f7b8) at connection.c:43
#12 0x0808c1c4 in worker_thread (thd=0x80f0558, dummy=0x80ef5c0)
     at worker.c:544
#13 0xb7e9fea6 in dummy_worker (opaque=0x80f0558)
     at threadproc/unix/thread.c:142
#14 0xb7e3646b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#15 0xb7db573e in clone () from /lib/tls/i686/cmov/libc.so.6

(gdb) frame 5
#5  0x0808a103 in ap_byterange_filter (f=0x832c370, bb=0x832d440)
     at byterange_filter.c:271
271                 if (apr_bucket_copy(ec, &foo) != APR_SUCCESS) {
(gdb) l
266             do {
267                 apr_bucket *foo;
268                 const char *str;
269                 apr_size_t len;
270
271                 if (apr_bucket_copy(ec, &foo) != APR_SUCCESS) {
272                     /* As above; this should not fail since the bucket has
273                      * a known length, but just to be sure, this takes
274                      * care of uncopyable buckets that do somehow manage
275                      * to slip through.  */
(gdb) frame 6
#6  0xb7cab180 in cache_out_filter (f=0x832d428, bb=0x832d440)
     at mod_cache.c:298
298         return ap_pass_brigade(f->next, bb);
(gdb) l
293         /* This filter is done once it has served up its content */
294         ap_remove_output_filter(f);
295
296         ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, r->server,
297                      "cache: serving %s", r->uri);
298         return ap_pass_brigade(f->next, bb);
299     }
300
301
302     /*
---------------------8<-----------------------------


/Nikke - slightly confused...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Calm down. It's only ones and zeros.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Mime
View raw message