[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: Windows XP Pro/Linux PHP Version: 4.1.0 New Comment: I've used a packet logger and have found that PHP seems to halt transmission around a php instruction. The socket is actually closed, I'm not sure if there needs to be an 'END' string at the end of an http session, but there are no CR's or anything like that on the end. Previous Comments: [2002-01-18 10:54:20] [EMAIL PROTECTED] I've tried the script on PHP 4.0.6, Windows 2000 Pro, Apache 1.3.22, php installed as a module. If I use a download manager to access the script it works. I use Mass Downloader 2.2 and to get the file I write something like this to the url address: http://localhost/bug.php. The program starts downloading the file and after downloading 28.55 Mb stops, but it doesn't say that the download finished and after 5 sec. it starts downloading the file again. If I set the for loop only to 100 the result is the same, after the program transfers 2.5 Kb it waits for 5 sec. after he tryes again to download it. But if I try this with IE (when the loop is set to 100) everything it's ok. So, after running this tests, I think that the problem is not that PHP does not support large outputs, but the browser. (28.55 Mb it's a huge html file). I've tested IE with the loop set to 10 and it works. If I set the loop to 100 then I ran aout of memory, because my page file is only of 380 Mb. But maybe if I would have more memory everything would be OK. [2001-12-15 22:21:55] [EMAIL PROTECTED] Probably, Zeev is right about regarding [2001-12-12 20:33:45] [EMAIL PROTECTED] update. Since I didn't see active httpd process. httpd should close connection when PHP cannot execute script, anyway ;) (I suppose httpd is not closing connection. With my IE under w2k, networks may become ususable. Mozilla under linux halts. This is critical :) More detailed analysys is required. Any volanteers? [2001-12-15 11:20:23] [EMAIL PROTECTED] I don't think that our current analysis is correct. Take a look at the access log - I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not requested only once. Something about the way the server disconnects may cause IE to think that the page was not properly fetched, and make it try to reload it. That would be my guess... [2001-12-14 12:57:09] [EMAIL PROTECTED] I think this is critical [2001-12-12 20:33:45] [EMAIL PROTECTED] This problem reveals a memory limit bailout problem. Even if PHP exhsusted memory, script does not exit. PHP logs following logs many times. (Linux/PHP4.1.0, without output buffering) [13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 10240 bytes) in /home/yohgaki/public_html/bugs/14474/bug.php on line 4 Type is changed to Scripting Engine Problem. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14474 -- Edit this bug report at http://bugs.php.net/?id=14474edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: Windows XP Pro/Linux PHP Version: 4.1.0 New Comment: I've used a packet logger and have found that PHP seems to halt transmission around a php instruction. The socket is actually closed, I'm not sure if there needs to be an 'END' string at the end of an http session, but there are no CR's or anything like that on the end. Previous Comments: [2002-02-05 04:36:45] [EMAIL PROTECTED] I've used a packet logger and have found that PHP seems to halt transmission around a php instruction. The socket is actually closed, I'm not sure if there needs to be an 'END' string at the end of an http session, but there are no CR's or anything like that on the end. [2002-01-18 10:54:20] [EMAIL PROTECTED] I've tried the script on PHP 4.0.6, Windows 2000 Pro, Apache 1.3.22, php installed as a module. If I use a download manager to access the script it works. I use Mass Downloader 2.2 and to get the file I write something like this to the url address: http://localhost/bug.php. The program starts downloading the file and after downloading 28.55 Mb stops, but it doesn't say that the download finished and after 5 sec. it starts downloading the file again. If I set the for loop only to 100 the result is the same, after the program transfers 2.5 Kb it waits for 5 sec. after he tryes again to download it. But if I try this with IE (when the loop is set to 100) everything it's ok. So, after running this tests, I think that the problem is not that PHP does not support large outputs, but the browser. (28.55 Mb it's a huge html file). I've tested IE with the loop set to 10 and it works. If I set the loop to 100 then I ran aout of memory, because my page file is only of 380 Mb. But maybe if I would have more memory everything would be OK. [2001-12-15 22:21:55] [EMAIL PROTECTED] Probably, Zeev is right about regarding [2001-12-12 20:33:45] [EMAIL PROTECTED] update. Since I didn't see active httpd process. httpd should close connection when PHP cannot execute script, anyway ;) (I suppose httpd is not closing connection. With my IE under w2k, networks may become ususable. Mozilla under linux halts. This is critical :) More detailed analysys is required. Any volanteers? [2001-12-15 11:20:23] [EMAIL PROTECTED] I don't think that our current analysis is correct. Take a look at the access log - I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not requested only once. Something about the way the server disconnects may cause IE to think that the page was not properly fetched, and make it try to reload it. That would be my guess... [2001-12-14 12:57:09] [EMAIL PROTECTED] I think this is critical The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14474 -- Edit this bug report at http://bugs.php.net/?id=14474edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: Windows XP Pro/Linux PHP Version: 4.1.0 New Comment: Adding to my previous comment, I saw no: CR 0 CR Disconnect at the end of my http session. OK - The HTTP Request is not closed properly. Only got: blahblah blah blahbr CR blafjaskasdjadsjffont size=1$sample_write[$i] Disconnect There must be an CR0CR at the end of the reply. Previous Comments: [2002-02-05 04:36:55] [EMAIL PROTECTED] I've used a packet logger and have found that PHP seems to halt transmission around a php instruction. The socket is actually closed, I'm not sure if there needs to be an 'END' string at the end of an http session, but there are no CR's or anything like that on the end. [2002-02-05 04:36:45] [EMAIL PROTECTED] I've used a packet logger and have found that PHP seems to halt transmission around a php instruction. The socket is actually closed, I'm not sure if there needs to be an 'END' string at the end of an http session, but there are no CR's or anything like that on the end. [2002-01-18 10:54:20] [EMAIL PROTECTED] I've tried the script on PHP 4.0.6, Windows 2000 Pro, Apache 1.3.22, php installed as a module. If I use a download manager to access the script it works. I use Mass Downloader 2.2 and to get the file I write something like this to the url address: http://localhost/bug.php. The program starts downloading the file and after downloading 28.55 Mb stops, but it doesn't say that the download finished and after 5 sec. it starts downloading the file again. If I set the for loop only to 100 the result is the same, after the program transfers 2.5 Kb it waits for 5 sec. after he tryes again to download it. But if I try this with IE (when the loop is set to 100) everything it's ok. So, after running this tests, I think that the problem is not that PHP does not support large outputs, but the browser. (28.55 Mb it's a huge html file). I've tested IE with the loop set to 10 and it works. If I set the loop to 100 then I ran aout of memory, because my page file is only of 380 Mb. But maybe if I would have more memory everything would be OK. [2001-12-15 22:21:55] [EMAIL PROTECTED] Probably, Zeev is right about regarding [2001-12-12 20:33:45] [EMAIL PROTECTED] update. Since I didn't see active httpd process. httpd should close connection when PHP cannot execute script, anyway ;) (I suppose httpd is not closing connection. With my IE under w2k, networks may become ususable. Mozilla under linux halts. This is critical :) More detailed analysys is required. Any volanteers? [2001-12-15 11:20:23] [EMAIL PROTECTED] I don't think that our current analysis is correct. Take a look at the access log - I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not requested only once. Something about the way the server disconnects may cause IE to think that the page was not properly fetched, and make it try to reload it. That would be my guess... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14474 -- Edit this bug report at http://bugs.php.net/?id=14474edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474
Comment by: [EMAIL PROTECTED]
Old Reported By: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro/Linux
PHP Version: 4.1.0
New Comment:
I've tried the script on PHP 4.0.6, Windows 2000 Pro, Apache 1.3.22,
php installed as a module.
If I use a download manager to access the script it works.
I use Mass Downloader 2.2 and to get the file I write something like
this to the url address: http://localhost/bug.php.
The program starts downloading the file and after downloading 28.55 Mb
stops, but it doesn't say that the download finished and after 5 sec.
it starts downloading the file again. If I set the for loop only to 100
the result is the same, after the program transfers 2.5 Kb it waits for
5 sec. after he tryes again to download it.
But if I try this with IE (when the loop is set to 100) everything it's
ok.
So, after running this tests, I think that the problem is not that PHP
does not support large outputs, but the browser. (28.55 Mb it's a huge
html file).
I've tested IE with the loop set to 10 and it works.
If I set the loop to 100 then I ran aout of memory, because my page
file is only of 380 Mb. But maybe if I would have more memory
everything would be OK.
Previous Comments:
[2001-12-15 22:21:55] [EMAIL PROTECTED]
Probably, Zeev is right about regarding
[2001-12-12 20:33:45] [EMAIL PROTECTED]
update. Since I didn't see active httpd process.
httpd should close connection when PHP cannot execute script, anyway
;)
(I suppose httpd is not closing connection. With my IE under w2k,
networks may become ususable. Mozilla under linux halts. This is
critical :)
More detailed analysys is required. Any volanteers?
[2001-12-15 11:20:23] [EMAIL PROTECTED]
I don't think that our current analysis is correct. Take a look at the
access log - I'm pretty sure you'd see that the page is being
repeatedly requested by IE, and not requested only once.
Something about the way the server disconnects may cause IE to think
that the page was not properly fetched, and make it try to reload it.
That would be my guess...
[2001-12-14 12:57:09] [EMAIL PROTECTED]
I think this is critical
[2001-12-12 20:33:45] [EMAIL PROTECTED]
This problem reveals a memory limit bailout problem.
Even if PHP exhsusted memory, script does not exit.
PHP logs following logs many times. (Linux/PHP4.1.0, without output
buffering)
[13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608
bytes exhausted (tried to allocate 10240 bytes) in
/home/yohgaki/public_html/bugs/14474/bug.php on line 4
Type is changed to Scripting Engine Problem.
[2001-12-12 19:28:49] [EMAIL PROTECTED]
Note: this seems to be the same problem as #14222, but I can't seem to
append stuff to someone elses bug so...
This is something I first noticed when I upgraded from XP RC1 to WinXP
Final, when using PHP 4.0.6. I upgraded to 4.1.0 today, and it doesn't
solve the problem.
The php apache module doesn't seem able to handle outputting moderate
to large sized pages.
I have been able to reliably reproduce the problem with the following
script:
?PHP
set_time_limit(900);
for ($i = 0; $i100; $i++){
print This is line number . ($i+1) . br;
}
?
Viewing this page with internet explorer causes it to go into an almost
endless loop of relaoding the page. It will display the first few
'this line is number...' and then will reload the page over and over.
On some sessions IE will eventually show it's 'The page cannot be
displayed' page, and sometimes it will just reload indefinitly.
Viewing this page with Mozilla/Netscape doesn't have the same effect.
Mozilla doesn't go through the reload loop, but will not show the page
as it should either. There will be unexplained (no errors) jumps in
numbers/missing output such as:
This is line number 2368
This is line number 2369This is line number 2517
This is line number 2518
But the errors in output don't occur in the same spot each time. And
evenutally (well short of 1,000,000 lines) the output will just stop
with no error, often in mid line.
I have found that adding 'flush();' just after the 'print This is
line...' seems to fix the problem.
Edit this bug report at http://bugs.php.net/?id=14474edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro/Linux
PHP Version: 4.1.0
New Comment:
I don't think that our current analysis is correct. Take a look at the access log -
I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not
requested only once.
Something about the way the server disconnects may cause IE to think that the page was
not properly fetched, and make it try to reload it. That would be my guess...
Previous Comments:
[2001-12-14 12:57:09] [EMAIL PROTECTED]
I think this is critical
[2001-12-12 20:33:45] [EMAIL PROTECTED]
This problem reveals a memory limit bailout problem.
Even if PHP exhsusted memory, script does not exit.
PHP logs following logs many times. (Linux/PHP4.1.0, without output buffering)
[13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608 bytes
exhausted (tried to allocate 10240 bytes) in
/home/yohgaki/public_html/bugs/14474/bug.php on line 4
Type is changed to Scripting Engine Problem.
[2001-12-12 19:28:49] [EMAIL PROTECTED]
Note: this seems to be the same problem as #14222, but I can't seem to append stuff to
someone elses bug so...
This is something I first noticed when I upgraded from XP RC1 to WinXP Final, when
using PHP 4.0.6. I upgraded to 4.1.0 today, and it doesn't solve the problem.
The php apache module doesn't seem able to handle outputting moderate to large sized
pages.
I have been able to reliably reproduce the problem with the following script:
?PHP
set_time_limit(900);
for ($i = 0; $i100; $i++){
print This is line number . ($i+1) . br;
}
?
Viewing this page with internet explorer causes it to go into an almost endless loop
of relaoding the page. It will display the first few 'this line is number...' and
then will reload the page over and over. On some sessions IE will eventually show
it's 'The page cannot be displayed' page, and sometimes it will just reload
indefinitly.
Viewing this page with Mozilla/Netscape doesn't have the same effect. Mozilla doesn't
go through the reload loop, but will not show the page as it should either. There
will be unexplained (no errors) jumps in numbers/missing output such as:
This is line number 2368
This is line number 2369This is line number 2517
This is line number 2518
But the errors in output don't occur in the same spot each time. And evenutally (well
short of 1,000,000 lines) the output will just stop with no error, often in mid line.
I have found that adding 'flush();' just after the 'print This is line...' seems to
fix the problem.
Edit this bug report at http://bugs.php.net/?id=14474edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro/Linux
PHP Version: 4.1.0
New Comment:
Probably, Zeev is right about regarding
[2001-12-12 20:33:45] [EMAIL PROTECTED]
update. Since I didn't see active httpd process.
httpd should close connection when PHP cannot execute script, anyway ;)
(I suppose httpd is not closing connection. With my IE under w2k, networks may become
ususable. Mozilla under linux halts. This is critical :)
More detailed analysys is required. Any volanteers?
Previous Comments:
[2001-12-15 11:20:23] [EMAIL PROTECTED]
I don't think that our current analysis is correct. Take a look at the access log -
I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not
requested only once.
Something about the way the server disconnects may cause IE to think that the page was
not properly fetched, and make it try to reload it. That would be my guess...
[2001-12-14 12:57:09] [EMAIL PROTECTED]
I think this is critical
[2001-12-12 20:33:45] [EMAIL PROTECTED]
This problem reveals a memory limit bailout problem.
Even if PHP exhsusted memory, script does not exit.
PHP logs following logs many times. (Linux/PHP4.1.0, without output buffering)
[13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608 bytes
exhausted (tried to allocate 10240 bytes) in
/home/yohgaki/public_html/bugs/14474/bug.php on line 4
Type is changed to Scripting Engine Problem.
[2001-12-12 19:28:49] [EMAIL PROTECTED]
Note: this seems to be the same problem as #14222, but I can't seem to append stuff to
someone elses bug so...
This is something I first noticed when I upgraded from XP RC1 to WinXP Final, when
using PHP 4.0.6. I upgraded to 4.1.0 today, and it doesn't solve the problem.
The php apache module doesn't seem able to handle outputting moderate to large sized
pages.
I have been able to reliably reproduce the problem with the following script:
?PHP
set_time_limit(900);
for ($i = 0; $i100; $i++){
print This is line number . ($i+1) . br;
}
?
Viewing this page with internet explorer causes it to go into an almost endless loop
of relaoding the page. It will display the first few 'this line is number...' and
then will reload the page over and over. On some sessions IE will eventually show
it's 'The page cannot be displayed' page, and sometimes it will just reload
indefinitly.
Viewing this page with Mozilla/Netscape doesn't have the same effect. Mozilla doesn't
go through the reload loop, but will not show the page as it should either. There
will be unexplained (no errors) jumps in numbers/missing output such as:
This is line number 2368
This is line number 2369This is line number 2517
This is line number 2518
But the errors in output don't occur in the same spot each time. And evenutally (well
short of 1,000,000 lines) the output will just stop with no error, often in mid line.
I have found that adding 'flush();' just after the 'print This is line...' seems to
fix the problem.
Edit this bug report at http://bugs.php.net/?id=14474edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro/Linux
PHP Version: 4.1.0
New Comment:
I think this is critical
Previous Comments:
[2001-12-12 20:33:45] [EMAIL PROTECTED]
This problem reveals a memory limit bailout problem.
Even if PHP exhsusted memory, script does not exit.
PHP logs following logs many times. (Linux/PHP4.1.0, without output buffering)
[13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608 bytes
exhausted (tried to allocate 10240 bytes) in
/home/yohgaki/public_html/bugs/14474/bug.php on line 4
Type is changed to Scripting Engine Problem.
[2001-12-12 19:28:49] [EMAIL PROTECTED]
Note: this seems to be the same problem as #14222, but I can't seem to append stuff to
someone elses bug so...
This is something I first noticed when I upgraded from XP RC1 to WinXP Final, when
using PHP 4.0.6. I upgraded to 4.1.0 today, and it doesn't solve the problem.
The php apache module doesn't seem able to handle outputting moderate to large sized
pages.
I have been able to reliably reproduce the problem with the following script:
?PHP
set_time_limit(900);
for ($i = 0; $i100; $i++){
print This is line number . ($i+1) . br;
}
?
Viewing this page with internet explorer causes it to go into an almost endless loop
of relaoding the page. It will display the first few 'this line is number...' and
then will reload the page over and over. On some sessions IE will eventually show
it's 'The page cannot be displayed' page, and sometimes it will just reload
indefinitly.
Viewing this page with Mozilla/Netscape doesn't have the same effect. Mozilla doesn't
go through the reload loop, but will not show the page as it should either. There
will be unexplained (no errors) jumps in numbers/missing output such as:
This is line number 2368
This is line number 2369This is line number 2517
This is line number 2518
But the errors in output don't occur in the same spot each time. And evenutally (well
short of 1,000,000 lines) the output will just stop with no error, often in mid line.
I have found that adding 'flush();' just after the 'print This is line...' seems to
fix the problem.
Edit this bug report at http://bugs.php.net/?id=14474edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
