On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
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}
Quick question:
What is shown by
- print ec
Is the 'smashed' bucket always in the same position of the brigade (e.g always
the first, second,...)
Regards
Rüdiger
