DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=44447>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44447 ------- Additional Comments From [EMAIL PROTECTED] 2008-02-19 05:41 ------- Created an attachment (id=21560) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21560&action=view) A patch created by Konrad and me, fixing the problem. We added calls to apr_bucket_setaside(b, r->pool) for every APR_BUCKET_REMOVE(b) followed by APR_BRIGADE_INSERT_TAIL(ctx->tmp_bb, b). Analysis of the problem: The handler function in mod_include (includes_module()) gets called with TRANSIENT buckets pointing at a buffer allocated using malloc. The caller does this by calling ap_rwrite. (This won't happen for static resources, since we would get mmap'ed buckets or normal heap buckets, if mmap is not available). Whenever a directive crosses a bucket boundary, the mod_include parser in send_parsed_content will append the current bucket (containing part of the directive) to the brigade in ctx->tmp_bb to keep it around until the directive is completed in another bucket. If the end of the currently parsed bucket brigade is reached before the end of the directive is found, send_parsed_content returns, leaving the kept buckets in ctx->tmp_bb. After the call to ap_rwrite returns, the upstream module frees the buffer, invalidating any buckets the mod_include has kept in ctx->tmp_bb, since there is no call to apr_bucket_setaside() in mod_include. Our fix is straight-forward and leaves out error checking for the following reasons: * always calling setaside is simpler than checking the tmp_bb before exiting send_parsed_content * setaside is a no-op in the usual case where a static resource is filtered, calling it introduces little overhead * Checking the return code of apr_bucket_setaside would not improve things much: if it worked without setaside, although setaside is not implemented, it will continue to work correctly, if it didn't work before (for some custom bucket type), then it will stay that way. The existing bucket types either implement setaside correctly after they have been read or have a no-op implementation of setaside. * Using ap_save_brigade for the error checking aspect of it would require larger changes (it needs a second brigade to copy from) and would add nothing: the error recovery strategy is to call apr_bucket_read for it's side-effect of morphing the bucket. apr_bucket_read has been applied to the bucket before we reach our call to setaside, doing it again has probably no additional effect. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
