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=39605>. 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=39605 ------- Additional Comments From [EMAIL PROTECTED] 2006-05-18 21:29 ------- Yeah, that's helpful. I'm totally in favor of anything that makes stuff easier to diagnose. Looks like the call stack is this: window_handler * svn_stream_write ** brigade_write_fn *** apr_brigade_write **** ap_filter_flush ***** ap_pass_brigade ****** ap_byterange_filter ******* ap_pass_brigade ******** ap_content_length_filter ********* ap_pass_brigade ********** chunk_filter *********** ap_pass_brigade ************ core_output_filter <- sets aborted ... ** svn_stream_write again ... ************ core_output_filter again <- errors Subversion's only use of aborted seems to be this in dav_svn__send_xml: /* ### check for an aborted connection, since the brigade functions don't appear to be return useful errors when the connection is dropped. */ if (output->c->aborted) return svn_error_create(SVN_ERR_APMOD_CONNECTION_ABORTED, 0, NULL); If the contract on brigade writing is that the caller should check c->aborted before and after, then perhaps this should be moved into brigade_write_fn. I will take it up on the Subversion mailing list and see what happens. -- 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]
