On 6 Jun 2001, Jeff Trawick wrote:
> <[EMAIL PROTECTED]> writes:
>
> > > Note that with a simple situation I just recreated, the mmap bucket
> > > for a small file is being held by the content-length filter (it did
> > > ap_save_brigade).
> > >
> > > I'm confused... What would ap_sub_req_output_filter() be able to do
> > > to help?
> >
> > That depends. Was this a sub-request? If so, then when the
> > sub_req_output_filter was called, it would have converted the mmap bucket
> > into a heap bucket. If this wasn't a sub-request, then you don't really
> > have a problem. The only time this should still be a problem, is if the
> > file is >9k, and for some reason we didn't stream it. I can't think of
> > when that would happen though.
>
> The file/mmap bucket was created for a sub-request by handle_include.
> Here is the backtrace from when we get to ap_content_length_filter:
>
> #0 ap_content_length_filter (f=0x42089014, b=0x42093014) at
> protocol.c:853
> #1 0x80b60bf in ap_pass_brigade (next=0x42089014, bb=0x42093014) at
> util_filter.c:242
> #2 0x807751d in ap_byterange_filter (f=0x42088014, bb=0x42093014) at
> http_protocol.c:2263
> #3 0x80b60bf in ap_pass_brigade (next=0x42088014, bb=0x42093014) at
> util_filter.c:242
> #4 0x806c61d in send_parsed_content (bb=0xbfff8e58, r=0x42065014,
> f=0x42087014) at mod_include.c:2601
> #5 0x806ccab in includes_filter (f=0x42087014, b=0x42093014) at
> mod_include.c:2770
> #6 0x80b60bf in ap_pass_brigade (next=0x42087014, bb=0x42093014) at
> util_filter.c:242
> #7 0x80c0049 in ap_sub_req_output_filter (f=0x4206a014,
> bb=0x42093014) at request.c:813
> #8 0x80b60bf in ap_pass_brigade (next=0x4206a014, bb=0x42093014) at
> util_filter.c:242
> #9 0x80bdc7c in default_handler (r=0x42065014) at core.c:2995
> #10 0x80a8c71 in ap_run_handler (r=0x42065014) at config.c:133
> #11 0x80a938e in ap_invoke_handler (r=0x42065014) at config.c:292
> #12 0x80c0b3d in ap_run_sub_req (r=0x42065014) at request.c:1100
> #13 0x806868b in handle_include (ctx=0x4204e014, bb=0xbfffd4b8,
> r=0x41fe5014, f=0x42040014, head_ptr=0x81309a0,
> inserted_head=0xbfffd448)
> at mod_include.c:850
> #14 0x806c2bd in send_parsed_content (bb=0xbfffd4b8, r=0x41fe5014,
> f=0x42040014) at mod_include.c:2516
> #15 0x806ccab in includes_filter (f=0x42040014, b=0x42082014) at
> mod_include.c:2770
> #16 0x80b60bf in ap_pass_brigade (next=0x42040014, bb=0x4204c014) at
> util_filter.c:242
> #17 0x80bdc7c in default_handler (r=0x41fe5014) at core.c:2995
> #18 0x80a8c71 in ap_run_handler (r=0x41fe5014) at config.c:133
> #19 0x80a938e in ap_invoke_handler (r=0x41fe5014) at config.c:292
> #20 0x80788f1 in process_request_internal (r=0x41fe5014) at
> http_request.c:378
> #21 0x8078a37 in ap_process_request (r=0x41fe5014) at
> http_request.c:444
> #22 0x8073543 in ap_process_http_connection (c=0x41fdb014) at
> http_core.c:280
> #23 0x80b4811 in ap_run_process_connection (c=0x41fdb014) at
> connection.c:82
> #24 0x80b4a38 in ap_process_connection (c=0x41fdb014) at connection.c:216
So yeah, if we added the logic to the sub-req-output-filter to do the
conversion, this problem would be solved. The logic is already in
core_output_filter, it's just a simple copy and paste.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
