Cliff Woolley <[EMAIL PROTECTED]> writes:
[...]
> Zuh? This is completely unnecessary. The only time inserting can corrupt
> a brigade is if the bucket being inserted is still on some other brigade
Thanks, Cliff. I guess I was getting confused by the
warnings in the apr_ring.h docs. The core file I'm
looking at (logio disabled) is pretty weird:
% gdb /usr/local/apache2/bin/httpd -core
/home/c/apache/modperl-2.0/t/core.9055
[...]
#0 0x0000002a9590b2ca in apr_bucket_free (mem=0x35b39e8)
at buckets/apr_buckets_alloc.c:174
174 apr_allocator_free(list->allocator, node->memnode);
(gdb) bt
#0 0x0000002a9590b2ca in apr_bucket_free (mem=0x35b39e8)
at buckets/apr_buckets_alloc.c:174
#1 0x0000002a9590b976 in heap_bucket_destroy (data=0x35afe48)
at buckets/apr_buckets_heap.c:35
#2 0x0000002a9590a440 in apr_brigade_cleanup (data=0x35b39e8)
at buckets/apr_brigade.c:43
#3 0x0000002a9590a47e in apr_brigade_destroy (b=0x35b3a78)
at buckets/apr_brigade.c:52
#4 0x000000000043c186 in core_output_filter (f=0x35ae4a0, b=0x35b3a78)
at core.c:4339
#5 0x00000000004337c7 in ap_pass_brigade (next=0x35b39e8, bb=0x35bca08)
at util_filter.c:511
#6 0x0000000000423431 in ap_process_request (r=0x35bca78)
at http_request.c:269
...
(gdb) f 4
#4 0x000000000043c186 in core_output_filter (f=0x35ae4a0, b=0x35b3a78)
at core.c:4339
4339 apr_brigade_destroy(b);
(gdb) p nvec
$1 = 2
(gdb) p (char *)vec[0].iov_base
$2 = 0x35b39e8 "X:[\003"
(gdb) p (char *)vec[1].iov_base
$3 = 0x35b59f8 "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n
<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not
Found</h1>\n<p>The requested URL /TestCompat__send_fd was not found on
this server.</p"...
Note that vec[0].iov_base should be where the headers are, and 0x35b39e8
is the memory chunk that's causing the segfault in apr_bucket_free:
(gdb) f 0
#0 0x0000002a9590b2ca in apr_bucket_free (mem=0x35b39e8)
at buckets/apr_buckets_alloc.c:174
174 apr_allocator_free(list->allocator, node->memnode);
(gdb) p *node
$4 = {size = 56285592, alloc = 0x0, memnode = 0x35bca08, next = 0x35ad9a0}
(gdb) p list
$5 = (apr_bucket_alloc_t *) 0x0
This segfault started appearing this weekend, but it only happens
on about 1/3 of the mp2 test suite runs. When it occurs, it's
always the "noexist.txt" test in t/compat/send_fd that triggers it.
There are no modperl functions involved in the stacktrace because
the mp2 handler is just returning a 404 for apache to deal with as
usual.
At this point I'm stumped, so any tips would be really appreciated.
--
Joe Schaefer
