> -----Ursprüngliche Nachricht----- > Von: Niklas Edmundsson > Gesendet: Donnerstag, 21. Februar 2008 22:10 > An: [email protected] > Betreff: Re: httpd 2.2.8 segfaults > > On Wed, 20 Feb 2008, Niklas Edmundsson wrote: > > > In any case, I should probably try to figure out how to > reproduce this thing. > > All coredumps I've looked at have been when serving DVD > images, which of > > course works flawlessly when I try it... > > OK, I've been able to reproduce this, and it looks really bad because: > > - I'm able to reproduce without having mod_cache loaded, ie. vanilla > httpd. > - It's as easy as continuing an aborted download, so it's a trivial > DOS. > > So, to reproduce I did: > 1) Download 2222288895 bytes of the total 4444577792 bytes of a DVD > image (debian-31r7-i386-binary-2.iso if you're curious). > 2) Continue the download by doing wget -cS http://whatever/file.iso > > This coredumps the server, immediately closing the connection to the > client. > > Backtrace of coredump is: > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7cefca6 in kill () from /lib/tls/i686/cmov/libc.so.6 > #2 0x08089a03 in sig_coredump (sig=11) at mpm_common.c:1235 > #3 <signal handler called> > #4 0x00000000 in ?? () > #5 0x08093010 in ap_byterange_filter (f=0x81606a0, bb=0x8161360) > at byterange_filter.c:271 > #6 0x0808aec5 in ap_pass_brigade (next=0x81606a0, bb=0x8161360) > at util_filter.c:526 > #7 0x08077576 in default_handler (r=0x815f968) at core.c:3740 > #8 0x0807df8d in ap_run_handler (r=0x815f968) at config.c:157 > #9 0x0807e6d7 in ap_invoke_handler (r=0x815f968) at config.c:372 > #10 0x0808ea7c in ap_process_request (r=0x815f968) at > http_request.c:258 > #11 0x0808b543 in ap_process_http_connection (c=0x815bb08) at > http_core.c:190 > #12 0x08086df3 in ap_run_process_connection (c=0x815bb08) at > connection.c:43 > #13 0x08087274 in ap_process_connection (c=0x815bb08, csd=0x815b958) > at connection.c:178 > #14 0x08094b00 in process_socket (p=0x815b920, > sock=0x815b958, my_child_num=0, > my_thread_num=0, bucket_alloc=0x815d928) at worker.c:544 > #15 0x080953c8 in worker_thread (thd=0x812d378, dummy=0x815b460) > at worker.c:894 > #16 0xb7e87eac in dummy_worker (opaque=0x812d378) > at threadproc/unix/thread.c:142 > #17 0xb7e1846b in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #18 0xb7d9873e in clone () from /lib/tls/i686/cmov/libc.so.6 > > (gdb) dump_bucket ec > bucket=¨0¸(0x08161364) length=135664344 data=0x080641b0 > contents=[**unknown**] rc=n/a > > (gdb) print *ec > $1 = {link = {next = 0x815db00, prev = 0x8169a50}, type = 0x815d928, > length = 135664344, start = -5193905754803399840, data = 0x80641b0, > free = 0x8161390, list = 0x1} > > (gdb) print *ec->type > $2 = {name = 0x815b920 "¨À\v\b0ù\025\b\030Ñ\022\b¸9\026\b\030À\025\b", > num_func = 135641240, is_metadata = APR_BUCKET_DATA, > destroy = 0x816bd00, > read = 0x58, setaside = 0x815d928, split = 0x815d910, copy = 0} > > (gdb) dump_brigade bb > dump of brigade 0x8161360 > | type (address) | length | data addr > --------------------------------------------------- > 0 | FILE (0x0815db00) | 16777216 | 0x0815daa8 > 1 | FILE (0x0815db58) | 16777216 | 0x0815daa8 > <snip> > 265 | FILE (0x081699f8) | 16777216 | 0x0815daa8 > 266 | FILE (0x0815d948) | 15392768 | 0x0815daa8 > 267 | EOS (0x08169a50) | 0 | 0x00000000 > end of brigade
Hm. Looks like to me that APR_BRIGADE_SENTINEL(ec) is true, because next points to the first bucket in the brigade and prev to the last one. AFAIK the SENTINEL is not a valid bucket and does not contain valid bucket data. This should NEVER happen and as we see the byte range filter code is not prepared to handle this. Regards Rüdiger
