[Bug 57229] mod_sed dies on long lines

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57229

--- Comment #4 from Christophe JAILLET <ch...@wanadoo.fr> ---
Way to reproduce, sent by Kaufmann, Oliver:



1)
sample php code to reliably trigger the problem:

<?php
print "first line with newline (all good)<br>\n";
$myline="https://www.asl.com<br>";
$myline2="https://ge-dev.itools.de.cse.comfin.ge.com";
$mylength=strlen($myline);
$mylength2=strlen($myline2);
$mynum=178;
$bytes=$mynum*$mylength;
$bytes2=$mynum*$mylength2;
print "now printing one single matching line with $mynum*$mylength=$bytes bytes
expanding to $bytes2 bytes:<br>\n";
for ($i=0; $i < $mynum; $i++)
{
                print "$myline";
}
print "\nThis is a test line. If you see it, all is good. Else mod_sed
crashed.<br>\n"; 
?>



2)
Apache config snipplet:

…
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule reqtimeout_module modules/mod_reqtimeout.so
LoadModule filter_module modules/mod_filter.so
LoadModule sed_module modules/mod_sed.so
LoadModule mime_module modules/mod_mime.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule version_module modules/mod_version.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule unixd_module modules/mod_unixd.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule info_module modules/mod_info.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule php5_module modules/libphp5.so
AddHandler php5-script php
…
In vhost:
…
RequestHeader unset Accept-Encoding
AddOutputFilterByType Sed text/html text/css text/javascript
application/javascript
Header unset Content-Length
OutputSed
"s/https:\/\/www.asl.com/https:\/\/ge-dev.itools.de.cse.comfin.ge.com/g"


3)
Software: Apache 2.4.10 + mod_sed compiled from source.
mod_sed  source taken from trunk at the moment, but error also happened on
stock apache 2.4.10 release version, this is why we switched to trunk.
For our tests we have also compiled sed1.c with different #define INIT_BUF_SIZE
values (stock value is 1024). Error scales with this buffer size.
In our current test we have set INIT_BUF_SIZE to 8092 (not 8192).

5)
Remember: We have INIT_BUF_SIZE 8092 in this test.
a)
Ouput: nothing if $mynum>=176. Browser times out and says Connection Problem
(Message depends on Browser vendor of course).
b)
Output: correct if $mynum<=175;
first line with newline (all good)
now printing one single matching line with 175*23=4025 bytes expanding to 7350
bytes:
https://ge-dev.itools.de.cse.comfin.ge.com
…
Last line is also shown

c)
Beware: Sometimes (maybe on first request, but seldom) you may get output with
values near 176 as well. If you get output this way, you can see that
substitution stopped before all lines were processed. Output then shows
correctly substituted lines at the beginning but at the end the original lines
are shown and rest of document may be completely truncated. Usually if you see
this, you can try to reload the page and might then end up with an empty page
and the connection problem. With $mynum=178 you will always trigger the error.

Just run your own tests with different buffer sizes.

6)
Linux system: Redhat 6.5 x64
HW: HP Proliant G6 with 192GB of RAM
No other jobs or load on this test system.

Regards,
Oliver

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org