#25533 [Bgs]: or with strings is wrong
ID: 25533 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com Status: Bogus Bug Type: Feature/Change Request Operating System: * PHP Version: * New Comment: That is the very problem - it's quite obvious that noone there cares about it. No pride, like I said. But it was obviously not illogical to the person who made it work with '&'. Why isn't he here? That's what this project desperately needs - code ownership. When you divide programmers and bugfixers, you end up with a bunch of people who really DO not care. Previous Comments: [2003-09-16 14:25:27] [EMAIL PROTECTED] It is a thing that is in our view a) illogical and b) we don't care about. Not to your question. If we were to produce an error message we could instead implement any behaviour with the same amount of work - but to repeat - we don't care about. Thus it is undefined. And since it is undefined we will not provide examples for what it does because that would make it a documented feature we would have to take care about - and just to repeat - we don't care about. [2003-09-16 14:10:20] brad at info-link dot net In PHP: "10 Small Pigs" | "10.2 Little Piggies" = "10.smmm|t|mgsiggies" Seems to follow the Perl way of doing things... Each char in the first string is bitwise or'd with the corresponding char in the second string. I didn't test bitwise-&, ^, etc, but I would expect them to act similarly. Why not just add examples to the manual instead of saying it's undefined? Why allow an operation that you can't depend on - just throw a compiler error. [2003-09-16 13:47:37] [EMAIL PROTECTED] And what, in your opinion, should be the result of "10 Small Pigs" | "10.2 Little Piggies" ? The point is that logical (bitwise) operations are inherently not loosely typed. That's why the logical operators are (and will remain) undefined on strings. Use a cast at your own risk. [2003-09-16 13:39:18] spagmoid at yahoo dot com Let's see a few other things straight from the manual since you're all such EXPERTS on it: $foo = "0"; // $foo is string (ASCII 48) $foo += 2; // $foo is now an integer (2) $foo = 1 + "10.5";// $foo is float (11.5) $foo = 1 + "-1.3e3"; // $foo is float (-1299) $foo = 1 + "bob-1.3e3"; // $foo is integer (1) $foo = 1 + "bob3";// $foo is integer (1) $foo = 1 + "10 Small Pigs"; // $foo is integer (11) $foo = 4 + "10.2 Little Piggies"; // $foo is float (14.2) $foo = "10.0 pigs " + 1; // $foo is float (11) $foo = "10.0 pigs " + 1.0;// $foo is float (11) Does that look "UNDEFINED" to you??? Huh? Take that feature out and watch how many current PHP apps fail. You people have no sense of QUALITY whatsoever. NO PRIDE IN YOUR WORK. NO PRIDE IN PHP. [2003-09-16 13:33:11] spagmoid at yahoo dot com "The result of using other operators on strings is undefined." RTFM?? That line isn't in the manual you moron! You just made it up! Add it to the manual then, instead of improving your product. What a bunch of jackasses. THIS is in the manual: String conversion to numbers When a string is evaluated as a numeric value, the resulting value and type are determined as follows. 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/25533 -- Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [Opn]: or with strings is wrong
ID: 25533
User updated by: spagmoid at yahoo dot com
Reported By: spagmoid at yahoo dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: WinXP
PHP Version: 4.3.3
New Comment:
Let's see a few other things straight from the manual since you're all
such EXPERTS on it:
$foo = "0"; // $foo is string (ASCII 48)
$foo += 2; // $foo is now an integer (2)
$foo = 1 + "10.5";// $foo is float (11.5)
$foo = 1 + "-1.3e3"; // $foo is float (-1299)
$foo = 1 + "bob-1.3e3"; // $foo is integer (1)
$foo = 1 + "bob3";// $foo is integer (1)
$foo = 1 + "10 Small Pigs"; // $foo is integer (11)
$foo = 4 + "10.2 Little Piggies"; // $foo is float (14.2)
$foo = "10.0 pigs " + 1; // $foo is float (11)
$foo = "10.0 pigs " + 1.0;// $foo is float (11)
Does that look "UNDEFINED" to you??? Huh? Take that feature out and
watch how many current PHP apps fail. You people have no sense of
QUALITY whatsoever. NO PRIDE IN YOUR WORK. NO PRIDE IN PHP.
Previous Comments:
[2003-09-16 13:33:11] spagmoid at yahoo dot com
"The result of using other operators on strings is undefined."
RTFM?? That line isn't in the manual you moron! You just made it up!
Add it to the manual then, instead of improving your product. What a
bunch of jackasses.
THIS is in the manual:
String conversion to numbers
When a string is evaluated as a numeric value, the resulting value and
type are determined as follows.
[2003-09-16 13:25:49] [EMAIL PROTECTED]
Here's your statement:
"PHP has two string operators ('.' and '.=', RTFM). The result of using
other operators on strings is undefined."
[2003-09-16 13:15:16] [EMAIL PROTECTED]
Not a bug -> Bogus
DON'T TOUCH THE STATUS!
[2003-09-16 12:36:15] spagmoid at yahoo dot com
If I leave the status as it is, noone will read it again.
I'm doing an article comparing idiosyncrasies of PHP vs ASP. Can I get
a statement from the PHP community along the lines of:
"It is the opinion of the PHP Community that ideally, bitwise AND
should work on strings, and bitwise OR should not. While this may
appear tremendously stupid, it is actually quite logical and
intelligent."
[2003-09-16 11:45:54] [EMAIL PROTECTED]
We won't be changing this, because we don't see a need for performing
bitwise logical operations on strings.
If you feel so strongly about it, you are welcome to submit a patch to
the developer list and see if enough people think it's worthwhile
including in PHP.
Please keep the status of this report as it is.
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/25533
--
Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [Bgs->Opn]: or with strings is wrong
ID: 25533
User updated by: spagmoid at yahoo dot com
Reported By: spagmoid at yahoo dot com
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: WinXP
PHP Version: 4.3.3
New Comment:
"The result of using other operators on strings is undefined."
RTFM?? That line isn't in the manual you moron! You just made it up!
Add it to the manual then, instead of improving your product. What a
bunch of jackasses.
THIS is in the manual:
String conversion to numbers
When a string is evaluated as a numeric value, the resulting value and
type are determined as follows.
Previous Comments:
[2003-09-16 13:25:49] [EMAIL PROTECTED]
Here's your statement:
"PHP has two string operators ('.' and '.=', RTFM). The result of using
other operators on strings is undefined."
[2003-09-16 13:15:16] [EMAIL PROTECTED]
Not a bug -> Bogus
DON'T TOUCH THE STATUS!
----
[2003-09-16 12:36:15] spagmoid at yahoo dot com
If I leave the status as it is, noone will read it again.
I'm doing an article comparing idiosyncrasies of PHP vs ASP. Can I get
a statement from the PHP community along the lines of:
"It is the opinion of the PHP Community that ideally, bitwise AND
should work on strings, and bitwise OR should not. While this may
appear tremendously stupid, it is actually quite logical and
intelligent."
[2003-09-16 11:45:54] [EMAIL PROTECTED]
We won't be changing this, because we don't see a need for performing
bitwise logical operations on strings.
If you feel so strongly about it, you are welcome to submit a patch to
the developer list and see if enough people think it's worthwhile
including in PHP.
Please keep the status of this report as it is.
[2003-09-16 11:25:19] spagmoid at yahoo dot com
Then why can you add strings with +?
Why can you logically AND strings with &?
Why can you multiply strings with *?
Does consistency matter in the slightest to you people?
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/25533
--
Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [Bgs->Opn]: or with strings is wrong
ID: 25533 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.3 New Comment: If I leave the status as it is, noone will read it again. I'm doing an article comparing idiosyncrasies of PHP vs ASP. Can I get a statement from the PHP community along the lines of: "It is the opinion of the PHP Community that ideally, bitwise AND should work on strings, and bitwise OR should not. While this may appear tremendously stupid, it is actually quite logical and intelligent." Previous Comments: [2003-09-16 11:45:54] [EMAIL PROTECTED] We won't be changing this, because we don't see a need for performing bitwise logical operations on strings. If you feel so strongly about it, you are welcome to submit a patch to the developer list and see if enough people think it's worthwhile including in PHP. Please keep the status of this report as it is. ---- [2003-09-16 11:25:19] spagmoid at yahoo dot com Then why can you add strings with +? Why can you logically AND strings with &? Why can you multiply strings with *? Does consistency matter in the slightest to you people? [2003-09-16 11:19:48] [EMAIL PROTECTED] You can't logically OR strings. Now, forget about it ;) ---- [2003-09-15 23:15:50] spagmoid at yahoo dot com if $A+$B works, then $A|$B should work as well. '|' is not '.' [2003-09-15 22:55:58] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. echo (int)$A|(int)$B; 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/25533 -- Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [Bgs->Opn]: or with strings is wrong
ID: 25533 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.3 New Comment: Then why can you add strings with +? Why can you logically AND strings with &? Why can you multiply strings with *? Does consistency matter in the slightest to you people? Previous Comments: [2003-09-16 11:19:48] [EMAIL PROTECTED] You can't logically OR strings. Now, forget about it ;) [2003-09-16 11:00:47] spagmoid at yahoo dot com No. I want a 3rd opinion. [2003-09-16 09:48:42] [EMAIL PROTECTED] No. Now forget about it. [2003-09-15 23:15:50] spagmoid at yahoo dot com if $A+$B works, then $A|$B should work as well. '|' is not '.' [2003-09-15 22:55:58] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. echo (int)$A|(int)$B; 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/25533 -- Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [Bgs->Opn]: or with strings is wrong
ID: 25533 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.3 New Comment: No. I want a 3rd opinion. Previous Comments: [2003-09-16 09:48:42] [EMAIL PROTECTED] No. Now forget about it. [2003-09-15 23:15:50] spagmoid at yahoo dot com if $A+$B works, then $A|$B should work as well. '|' is not '.' [2003-09-15 22:55:58] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. echo (int)$A|(int)$B; [2003-09-15 22:52:33] spagmoid at yahoo dot com Uhh.. "do not"? That's your solution? You're kidding, right? OK how about this. Values returned from mysql. $A = "146"; $B = "2"; echo $A|$B; result: 346 [2003-09-14 20:08:36] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Do not perform bitwise operations on strings. 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/25533 -- Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [Bgs->Opn]: or with strings is wrong
ID: 25533 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open -Bug Type: Math related +Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.3 New Comment: if $A+$B works, then $A|$B should work as well. '|' is not '.' Previous Comments: [2003-09-15 22:55:58] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. echo (int)$A|(int)$B; [2003-09-15 22:52:33] spagmoid at yahoo dot com Uhh.. "do not"? That's your solution? You're kidding, right? OK how about this. Values returned from mysql. $A = "146"; $B = "2"; echo $A|$B; result: 346 [2003-09-14 20:08:36] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Do not perform bitwise operations on strings. [2003-09-14 11:47:47] spagmoid at yahoo dot com Description: This is a difficult issue to search for dups on. Strings used with pipe OR "|" do something weird. Here it is: echo "146"|"2"; result is "346" echo (int)"146"|"2"; result is correct "146"; -- Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [Bgs->Opn]: or with strings is wrong
ID: 25533 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open Bug Type: Math related Operating System: WinXP PHP Version: 4.3.3 New Comment: Uhh.. "do not"? That's your solution? You're kidding, right? OK how about this. Values returned from mysql. $A = "146"; $B = "2"; echo $A|$B; result: 346 Previous Comments: [2003-09-14 20:08:36] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Do not perform bitwise operations on strings. [2003-09-14 11:47:47] spagmoid at yahoo dot com Description: This is a difficult issue to search for dups on. Strings used with pipe OR "|" do something weird. Here it is: echo "146"|"2"; result is "346" echo (int)"146"|"2"; result is correct "146"; -- Edit this bug report at http://bugs.php.net/?id=25533&edit=1
#25533 [NEW]: or with strings is wrong
From: spagmoid at yahoo dot com Operating system: WinXP PHP version: 4.3.3 PHP Bug Type: Math related Bug description: or with strings is wrong Description: This is a difficult issue to search for dups on. Strings used with pipe OR "|" do something weird. Here it is: echo "146"|"2"; result is "346" echo (int)"146"|"2"; result is correct "146"; -- Edit bug report at http://bugs.php.net/?id=25533&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25533&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25533&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25533&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25533&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25533&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25533&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25533&r=support Expected behavior: http://bugs.php.net/fix.php?id=25533&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25533&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25533&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25533&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25533&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25533&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25533&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25533&r=gnused
#17309 [Com]: pass by reference in call_user_func
ID: 17309
Comment by: spagmoid at yahoo dot com
Reported By: pmoor at netpeople dot ch
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.2.1
New Comment:
This is a good example of why the warning against call-time pass by
reference is a bad idea. Any function that accepts a reference should
be required to also have the parms use & at call time. And references
should be allowed as optional parameters ie:
function Blah(&$MayBeBlank=0)
Previous Comments:
[2002-10-24 16:06:14] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When you do ' call_user_func("pass_by_reference", $data ); ' you
actually pass the $data variable to the call_user_func first and that
function will internally pass $data to the function specified in the
first argument. Unless $data is passed to call_user_func by reference,
the call_user_func simply makes a copy of the $data variable and passes
that copy to the pass_by_reference function. Hence the 'invalid'
output, which you see.
If you do ' pass_by_reference( $data ); ' it works, because the
function has been defined to accept the parameter by reference.
[2002-07-05 11:34:57] bram at totalgsm dot net
This might be a duplicate of:
http://bugs.php.net/bug.php?id=17246
However, this test case is clearer.
[2002-07-05 11:34:10] bram at totalgsm dot net
This might be a duplicate of:
http://bugs.php.net/bug.php?id=17246
However, this test case is clearer.
[2002-07-05 11:32:05] bram at totalgsm dot net
A workaround might be using variable function name like
$func_name = 'pass_by_reference';
$funcname($data);
However this doesn't work if the $func_name is an array to call a user
method (which is a flaw in PHP :( )
[2002-05-20 11:01:03] pmoor at netpeople dot ch
i've disabled the "call-time pass-by-reference" option in my
configuration file.
now, when trying to call_user_func a function with
reference-parameters, it won't work, unless i
call-time-pass-by-reference my parameters despite the warning.
( this bug might be related to bug #17246 )
here a small example:
function pass_by_reference( &$param ) {
$param[] = "another entry";
}
$data = array( "a first entry" );
call_user_func( "pass_by_reference", $data );
var_dump($data);// $data contains only one element ( "a first entry" )
( == unexpected behaviour )
$data = array( "a first entry" );
call_user_func( "pass_by_reference", &$data ); // Warning: Call-time
pass-by-reference has been deprecated - argument passed by value; ...
var_dump($data);// $data contains both elements ( "a first entry",
"another entry" ) ( == expected behaviour )
--
Edit this bug report at http://bugs.php.net/?id=17309&edit=1
#24797 [Bgs->Opn]: feature request: way to close connection with client?
ID: 24797 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: WinXP PHP Version: 4.3.2 New Comment: I DO NOT WANT TO SEND DATA TO THE CLIENT AFTER THE CONNECTION IS CLOSED. NOWHERE DID I SAY THAT. That is what you people keep trying to tell me to do. I don't want to do that. I never wanted to do that. I will never want to do that. That is ridiculous. "The only time PHP can continue executing after the data stream has closed is when the browser closes the connection itself." I would be more inclined to believe this if you had understood any of the question. "The only signal PHP can send to the webserver is "I'm done executing." It sends this "signal" by terminating." There may be another way to send this signal, but I doubt if either of you are in a position to tell me. "explaining your question in detail and making an attempt at civility by not attacking those who take the time to respond." It was in detail. "A way to close the connection with the client, while keeping the script running?" That's it, period. It's not a complicated issue. Sending a form letter that doesn't even match the question is not "taking the time to respond". Previous Comments: [2003-07-26 18:35:39] [EMAIL PROTECTED] Again, through what mechanism do you intend to send data to the client *after* the connection is closed? But to address your original question. There is no way PHP can possibly close the data stream between itself and the client since this stream is handled by the webserver. The only signal PHP can send to the webserver is "I'm done executing." It sends this "signal" by terminating. At this point your script can not continue executing because, obviously, it has stopped. The only time PHP can continue executing after the data stream has closed is when the browser closes the connection itself. Now, that said, might I suggest you attempt to ilicit a more courteous response in the future by explaining your question in detail and making an attempt at civility by not attacking those who take the time to respond. [2003-07-26 16:22:52] spagmoid at yahoo dot com Jesus you people are dense. You lose the attitude. Then me try to explain this in a way you can understand: 1. script runs 2. script sends data 3. script ends connection, sending all data <- feature missing 4. script does other stuff 5. script exits [2003-07-26 12:32:28] [EMAIL PROTECTED] The message [EMAIL PROTECTED] included with his bogusifying was a template response. For the purposes of this bug reporting system Feature Requests and Bugs are largely equivalent. So scale back the attitude m'kay? Second, this *IS* bogus. As a quick look at the manual will show a chapter on "Connection Handling" in which you'll find a clearly documented reference to: http://www.php.net/manual/en/function.ignore-user-abort.php which will accomplish what you describe in the first half of your report. What you describe in the second half of your report directly contradicts the first half. You want the connection closed but you want to send the last of the mod_gzip data? [2003-07-25 10:26:46] spagmoid at yahoo dot com Why are you telling me this is not "a bug in PHP itself"? I didn't submit a bug, I submitted a feature change/request. That's why it says "FEATURE REQUEST" in about 20 places. register_shutdown_function() does not do what I described. I want the script to stay running AFTER the connection is closed. Data can still be sent in the function called by register_shutdown_function(), therefore the connection must still be OPEN. [2003-07-25 04:18:04] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Use register_shutdown_function() 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/24797 -- Edit this bug report at http://bugs.php.net/?id=24797&edit=1
#24797 [Bgs->Opn]: feature request: way to close connection with client?
ID: 24797 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: WinXP PHP Version: 4.3.2 New Comment: Jesus you people are dense. You lose the attitude. Then me try to explain this in a way you can understand: 1. script runs 2. script sends data 3. script ends connection, sending all data <- feature missing 4. script does other stuff 5. script exits Previous Comments: [2003-07-26 12:32:28] [EMAIL PROTECTED] The message [EMAIL PROTECTED] included with his bogusifying was a template response. For the purposes of this bug reporting system Feature Requests and Bugs are largely equivalent. So scale back the attitude m'kay? Second, this *IS* bogus. As a quick look at the manual will show a chapter on "Connection Handling" in which you'll find a clearly documented reference to: http://www.php.net/manual/en/function.ignore-user-abort.php which will accomplish what you describe in the first half of your report. What you describe in the second half of your report directly contradicts the first half. You want the connection closed but you want to send the last of the mod_gzip data? [2003-07-25 10:26:46] spagmoid at yahoo dot com Why are you telling me this is not "a bug in PHP itself"? I didn't submit a bug, I submitted a feature change/request. That's why it says "FEATURE REQUEST" in about 20 places. register_shutdown_function() does not do what I described. I want the script to stay running AFTER the connection is closed. Data can still be sent in the function called by register_shutdown_function(), therefore the connection must still be OPEN. [2003-07-25 04:18:04] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Use register_shutdown_function() ---- [2003-07-24 15:30:36] spagmoid at yahoo dot com Description: feature request: A way to close the connection with the client, while keeping the script running? Is this possible? Also helpful to do a flush that will result in final sending of data when using mod_gzip etc. -- Edit this bug report at http://bugs.php.net/?id=24797&edit=1
#24797 [Bgs->Opn]: feature request: way to close connection with client?
ID: 24797 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: WinXP PHP Version: 4.3.2 New Comment: Why are you telling me this is not "a bug in PHP itself"? I didn't submit a bug, I submitted a feature change/request. That's why it says "FEATURE REQUEST" in about 20 places. register_shutdown_function() does not do what I described. I want the script to stay running AFTER the connection is closed. Data can still be sent in the function called by register_shutdown_function(), therefore the connection must still be OPEN. Previous Comments: [2003-07-25 04:18:04] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Use register_shutdown_function() ---- [2003-07-24 15:30:36] spagmoid at yahoo dot com Description: feature request: A way to close the connection with the client, while keeping the script running? Is this possible? Also helpful to do a flush that will result in final sending of data when using mod_gzip etc. -- Edit this bug report at http://bugs.php.net/?id=24797&edit=1
#24797 [NEW]: feature request: way to close connection with client?
From: spagmoid at yahoo dot com Operating system: WinXP PHP version: 4.3.2 PHP Bug Type: Feature/Change Request Bug description: feature request: way to close connection with client? Description: feature request: A way to close the connection with the client, while keeping the script running? Is this possible? Also helpful to do a flush that will result in final sending of data when using mod_gzip etc. -- Edit bug report at http://bugs.php.net/?id=24797&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24797&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24797&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24797&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24797&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24797&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24797&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24797&r=support Expected behavior: http://bugs.php.net/fix.php?id=24797&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24797&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24797&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24797&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24797&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24797&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24797&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24797&r=gnused
#24781 [Opn]: Security lapse due to flaw in session.use_only_cookies
ID: 24781 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com Status: Open Bug Type: Session related Operating System: All PHP Version: 4.3.2 New Comment: Note: It also only happens right when sessions are first created, that way the page currently being viewed has no SID, but all the links in it do contain the SID. Tricky and evil. Previous Comments: [2003-07-24 10:12:22] spagmoid at yahoo dot com Sorry, there's no way I can subject our site to this risk again. I just thought I would notify about this problem. I believe what happened was proxy servers started cacheing pages that has SID's in the links. This caused users to start pouring in with identical SID's (different on each proxy, we surmise). It only happened to AOL users. It took 12 hours of hell just to figure out what was going on. Maybe a note in the session section of the manual that this can happen would help.. [2003-07-23 22:13:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-07-23 19:20:57] spagmoid at yahoo dot com Description: Our SID's have been leaking out today and becoming shared between 5+ users at once, causing massive corruption. Our theory is that session.use_only_cookies does not always work. It sometimes allows the SID to propagate in URL when cookies are disabled (noticed in Netscape not IE for some reason). -- Edit this bug report at http://bugs.php.net/?id=24781&edit=1
#24781 [Fbk->Opn]: Security lapse due to flaw in session.use_only_cookies
ID: 24781 User updated by: spagmoid at yahoo dot com Reported By: spagmoid at yahoo dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: All PHP Version: 4.3.2 New Comment: Sorry, there's no way I can subject our site to this risk again. I just thought I would notify about this problem. I believe what happened was proxy servers started cacheing pages that has SID's in the links. This caused users to start pouring in with identical SID's (different on each proxy, we surmise). It only happened to AOL users. It took 12 hours of hell just to figure out what was going on. Maybe a note in the session section of the manual that this can happen would help.. Previous Comments: [2003-07-23 22:13:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-07-23 19:20:57] spagmoid at yahoo dot com Description: Our SID's have been leaking out today and becoming shared between 5+ users at once, causing massive corruption. Our theory is that session.use_only_cookies does not always work. It sometimes allows the SID to propagate in URL when cookies are disabled (noticed in Netscape not IE for some reason). -- Edit this bug report at http://bugs.php.net/?id=24781&edit=1
#24781 [NEW]: Security lapse due to flaw in session.use_only_cookies
From: spagmoid at yahoo dot com Operating system: All PHP version: 4.3.2 PHP Bug Type: Session related Bug description: Security lapse due to flaw in session.use_only_cookies Description: Our SID's have been leaking out today and becoming shared between 5+ users at once, causing massive corruption. Our theory is that session.use_only_cookies does not always work. It sometimes allows the SID to propagate in URL when cookies are disabled (noticed in Netscape not IE for some reason). -- Edit bug report at http://bugs.php.net/?id=24781&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24781&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24781&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24781&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24781&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24781&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24781&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24781&r=support Expected behavior: http://bugs.php.net/fix.php?id=24781&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24781&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24781&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24781&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24781&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24781&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24781&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24781&r=gnused
#24291 [Bgs]: globals not working right
ID: 24291
User updated by: spagmoid at yahoo dot com
Reported By: spagmoid at yahoo dot com
Status: Bogus
Bug Type: Variables related
Operating System: winXP
PHP Version: 4.3.2
New Comment:
I don't find this, where is it?
Previous Comments:
[2003-06-22 16:59:23] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
.
[2003-06-22 16:57:44] spagmoid at yahoo dot com
Description:
globals aren't working right - in repro, no value is echoed
Reproduce code:
---
Wang();
function Wang()
{
global $A, $B;
$A = 3;
$B = &$A; // should work, doesn't
// $GLOBALS["B"] = &$A; // works
Chung();
}
function Chung()
{
global $A, $B;
echo $B;
}
--
Edit this bug report at http://bugs.php.net/?id=24291&edit=1
#24291 [NEW]: globals not working right
From: spagmoid at yahoo dot com
Operating system: winXP
PHP version: 4.3.2
PHP Bug Type: Variables related
Bug description: globals not working right
Description:
globals aren't working right - in repro, no value is echoed
Reproduce code:
---
Wang();
function Wang()
{
global $A, $B;
$A = 3;
$B = &$A; // should work, doesn't
// $GLOBALS["B"] = &$A; // works
Chung();
}
function Chung()
{
global $A, $B;
echo $B;
}
--
Edit bug report at http://bugs.php.net/?id=24291&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24291&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24291&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24291&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24291&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24291&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24291&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24291&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24291&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24291&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24291&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24291&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24291&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24291&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24291&r=gnused
#21262 [Fbk->Csd]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: We have heard of unrelated issues with SP1, and with M$ there's no going back. We will upgrade eventually, but I will accept this as resolved since others have reported this fix. Thanks to gmeakin! Previous Comments: [2003-02-04 05:19:20] [EMAIL PROTECTED] Why can't you install that SP1?? Others reported it fixes this issue, so.. [2003-02-03 22:45:20] [EMAIL PROTECTED] I can't install SP1 here, but I wouldn't be surprised. This does counter iliaa's "by design" theory. [2003-02-03 11:32:57] [EMAIL PROTECTED] [Update] Just to confirm further after many more hours of use that installing Micrsoft's WinXP Service Pack-1 has fixed this bug for me. [2003-01-29 00:06:12] [EMAIL PROTECTED] Does the solution provided by [EMAIL PROTECTED] fix the problem for you..? [2003-01-28 13:27:42] [EMAIL PROTECTED] I have managed to solve my problem with outputting large amounts of data under WinXP Home Edition, PHP 4.3.0 and Apache 2.0.44. I experienced this problem consistently with a php page that I had written. I installed Windows XP Service Pack-1 from Microsoft and it fixed the problem straight away. To convince myself further I tried the php script listed at the beginning of this bug thread which I previously experienced the same problem. This also works with the service pack installed. It looks like a bug on Microsoft's side of the fence. Try installing the service pack for yourself and email this thread with your results as it worked for me. Good luck. Regards 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Fbk->Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: I can't install SP1 here, but I wouldn't be surprised. This does counter iliaa's "by design" theory. Previous Comments: [2003-02-03 11:32:57] [EMAIL PROTECTED] [Update] Just to confirm further after many more hours of use that installing Micrsoft's WinXP Service Pack-1 has fixed this bug for me. [2003-01-29 00:06:12] [EMAIL PROTECTED] Does the solution provided by [EMAIL PROTECTED] fix the problem for you..? [2003-01-28 13:27:42] [EMAIL PROTECTED] I have managed to solve my problem with outputting large amounts of data under WinXP Home Edition, PHP 4.3.0 and Apache 2.0.44. I experienced this problem consistently with a php page that I had written. I installed Windows XP Service Pack-1 from Microsoft and it fixed the problem straight away. To convince myself further I tried the php script listed at the beginning of this bug thread which I previously experienced the same problem. This also works with the service pack installed. It looks like a bug on Microsoft's side of the fence. Try installing the service pack for yourself and email this thread with your results as it worked for me. Good luck. Regards [2003-01-22 20:13:36] [EMAIL PROTECTED] My attitude is a result of iliaa's disrespect for MY time and work on this. I have nothing but respect for people that volunteer to improve PHP. Like I am doing myself by trying to point out bugs. I don't get paid to try OVER AND OVER to get people to recognize problems, and it is less fun than just fixing them myself would be, I assure you. But I have other projects I am committed to. The most I can do is keep pushing through the bureaucratic atmosphere created by people more interesting in closing bugs than fixing them. As I mentioned before, it's very much like trying to get bugs fixed at Microsoft. I don't know why, but this open source project has managed to duplicate the beauracracy aspect of large corporations very well. Perhaps its a lack of accountability from the lack of personal code ownership. Anyway, I submit to you that in NO CASE should PHP exit in an error condition without showing an error message. If this is INTENDED behavior then let me see the words "memory exceeded, quitting". Until I see them, this is a bug. In fact, I very much doubt that this is intended behavior. When the buffer is full, PHP waits for it to be transmitted then continues. It does not simply crash. To state that crashing is "not a bug" shows a fundamental misunderstanding of programming, and indeed of the difference between all that is good and evil. [2003-01-22 19:55:14] [EMAIL PROTECTED] You really need to correct your attitude first. We're all volunteers here and don't get paid for this shit.. 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: My attitude is a result of iliaa's disrespect for MY time and work on this. I have nothing but respect for people that volunteer to improve PHP. Like I am doing myself by trying to point out bugs. I don't get paid to try OVER AND OVER to get people to recognize problems, and it is less fun than just fixing them myself would be, I assure you. But I have other projects I am committed to. The most I can do is keep pushing through the bureaucratic atmosphere created by people more interesting in closing bugs than fixing them. As I mentioned before, it's very much like trying to get bugs fixed at Microsoft. I don't know why, but this open source project has managed to duplicate the beauracracy aspect of large corporations very well. Perhaps its a lack of accountability from the lack of personal code ownership. Anyway, I submit to you that in NO CASE should PHP exit in an error condition without showing an error message. If this is INTENDED behavior then let me see the words "memory exceeded, quitting". Until I see them, this is a bug. In fact, I very much doubt that this is intended behavior. When the buffer is full, PHP waits for it to be transmitted then continues. It does not simply crash. To state that crashing is "not a bug" shows a fundamental misunderstanding of programming, and indeed of the difference between all that is good and evil. Previous Comments: [2003-01-22 19:55:14] [EMAIL PROTECTED] You really need to correct your attitude first. We're all volunteers here and don't get paid for this shit.. [2003-01-22 19:49:33] [EMAIL PROTECTED] This is not always reproducible, this is as good as we can come up with. It appears to only reproduce for people unwilling to do anything about it. [2003-01-22 19:47:57] [EMAIL PROTECTED] Please provide a SHORT but complete example script that can be used to reproduce this. (the one you provided doesn't cause any crashes) [2003-01-22 19:41:51] [EMAIL PROTECTED] You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Fbk->Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: This is not always reproducible, this is as good as we can come up with. It appears to only reproduce for people unwilling to do anything about it. Previous Comments: [2003-01-22 19:47:57] [EMAIL PROTECTED] Please provide a SHORT but complete example script that can be used to reproduce this. (the one you provided doesn't cause any crashes) [2003-01-22 19:41:51] [EMAIL PROTECTED] You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). [2003-01-16 10:20:56] [EMAIL PROTECTED] This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. [2003-01-15 16:44:33] [EMAIL PROTECTED] I am using Apache version 2.0.43 with the sapi php module. I downloaded the latest stable snapshot of php (4.3.1) but it still reproduced the same orignial problem discussed. Regards 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Bgs->Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: Reproducible crash +Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? Previous Comments: [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). [2003-01-16 10:20:56] [EMAIL PROTECTED] This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. [2003-01-15 16:44:33] [EMAIL PROTECTED] I am using Apache version 2.0.43 with the sapi php module. I downloaded the latest stable snapshot of php (4.3.1) but it still reproduced the same orignial problem discussed. Regards [2003-01-14 19:25:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip (and what apache version is it?) [2003-01-14 13:34:57] [EMAIL PROTECTED] I can confirm this bug including the for loop provided earlier in this bug thread. I am using php 4.3.0 with Apache 2.0.43 with Windows XP Home Edition. I found this bug report after noticing the same effect with a large piece of php that I have been writing. I have found that turning off error reporting in php.ini helps but does not solve the problem totally. I found that using the flush() function helped but was not a reliable solution. This seems a blatant problem which is making debugging and development almost impossible and very frustrating. Is there any update on confirming the bug? Regards 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Fbk->Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.3.0 New Comment: This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. Previous Comments: [2003-01-15 16:44:33] [EMAIL PROTECTED] I am using Apache version 2.0.43 with the sapi php module. I downloaded the latest stable snapshot of php (4.3.1) but it still reproduced the same orignial problem discussed. Regards [2003-01-14 19:25:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip (and what apache version is it?) [2003-01-14 13:34:57] [EMAIL PROTECTED] I can confirm this bug including the for loop provided earlier in this bug thread. I am using php 4.3.0 with Apache 2.0.43 with Windows XP Home Edition. I found this bug report after noticing the same effect with a large piece of php that I have been writing. I have found that turning off error reporting in php.ini helps but does not solve the problem totally. I found that using the flush() function helped but was not a reliable solution. This seems a blatant problem which is making debugging and development almost impossible and very frustrating. Is there any update on confirming the bug? Regards [2003-01-10 23:42:44] [EMAIL PROTECTED] Ridiculous.. how on earth can they look at this: PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 10240 bytes) And say its a bug in IE? I agree with the first assesment - this is a likely a CRITICAL bug. I have seen pages fail for no reason on linux too, who knows if this problem could be responsible. This needs to be looked at by someone at the top. [2003-01-10 20:58:22] [EMAIL PROTECTED] I had the exact same problem. I submitted a bug report. Bug smashers seemed to go off on some random tangent. Then decided all of a sudden that it was an IE problem (even though in my original report I clearly stated that there was a problem with Mozilla/Netscape output as well). My original bug report here: http://bugs.php.net/bug.php?id=14474 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 4.3.0
New Comment:
Ridiculous.. how on earth can they look at this:
PHP Fatal error: Allowed memory size of 8388608
bytes exhausted (tried to allocate 10240 bytes)
And say its a bug in IE?
I agree with the first assesment - this is a likely a CRITICAL bug. I
have seen pages fail for no reason on linux too, who knows if this
problem could be responsible. This needs to be looked at by someone at
the top.
Previous Comments:
[2003-01-10 20:58:22] [EMAIL PROTECTED]
I had the exact same problem. I submitted a bug report. Bug smashers
seemed to go off on some random tangent. Then decided all of a sudden
that it was an IE problem (even though in my original report I clearly
stated that there was a problem with Mozilla/Netscape output as well).
My original bug report here:
http://bugs.php.net/bug.php?id=14474
[2002-12-30 15:45:50] [EMAIL PROTECTED]
Well that's strange, can anyone else repro this? You may need to
refresh a few times for it to happen. I have been using PHP from the
command line for the last year because of this issue.
[2002-12-30 10:05:43] [EMAIL PROTECTED]
This does not seem to be a problem. I can not reproduce this crash with
the following code.
for($Loop=0 ; $Loop<1 ; $Loop++)
{
echo "blah $Loop ";
}
I am also using the SAPI version of PHP in Apache under Windows XP.
[2002-12-29 15:26:55] [EMAIL PROTECTED]
Then maybe this should be a doc change: "If you don't call flush() once
in a while, PHP will hang. This is not a bug. Hanging is
intentional."
This is a BUG. If it causes PHP to HANG before outputting the page,
then it is a BUG! FLUSH IS NOT SUPPOSED TO BE MANDATORY.
This also happens when outputting pages under 20K, but this example is
the best way to repro. And as I stated, implicit flushing does not fix
the problem either. Any delay in the loop fixes it.
Every time I submit something here, somebody spends 15 seconds on it
and marks it as bogus. When it is NOT. I WENT TO THE TIME OF
SUBMITTING THIS FOR A REASON, AND I AM NOT A JACKASS. I HAVE BEEN
PROGRAMMING FOR 15 YEARS. If you treat every bug report on here like
an idiot wrote it, only idiots are going to stick around to report
"bugs" for you. Spend a little more than 15 seconds on it.
I gave exact details and the simplest repro on earth, not to mention
the results of possible contributing factors. What else could you
possibly want. Why is it so hard to get problems even acknowledged
here? Maybe I should just mark them as bogus in the beginning to save
a little time. This is as bad as reporting bugs to Microsoft.
[2002-12-29 14:08:46] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
I think this is not a bug, but simply an issue of running out of
memory, because the data in the buffer simply gets too big. flush()
dumps the data inside the buffer to screen and clears the buffer, which
is why it wouldn't crash when flush() is used.
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/21262
--
Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 4.3.0
New Comment:
Well that's strange, can anyone else repro this? You may need to
refresh a few times for it to happen. I have been using PHP from the
command line for the last year because of this issue.
Previous Comments:
[2002-12-30 10:05:43] [EMAIL PROTECTED]
This does not seem to be a problem. I can not reproduce this crash with
the following code.
for($Loop=0 ; $Loop<1 ; $Loop++)
{
echo "blah $Loop ";
}
I am also using the SAPI version of PHP in Apache under Windows XP.
[2002-12-29 15:26:55] [EMAIL PROTECTED]
Then maybe this should be a doc change: "If you don't call flush() once
in a while, PHP will hang. This is not a bug. Hanging is
intentional."
This is a BUG. If it causes PHP to HANG before outputting the page,
then it is a BUG! FLUSH IS NOT SUPPOSED TO BE MANDATORY.
This also happens when outputting pages under 20K, but this example is
the best way to repro. And as I stated, implicit flushing does not fix
the problem either. Any delay in the loop fixes it.
Every time I submit something here, somebody spends 15 seconds on it
and marks it as bogus. When it is NOT. I WENT TO THE TIME OF
SUBMITTING THIS FOR A REASON, AND I AM NOT A JACKASS. I HAVE BEEN
PROGRAMMING FOR 15 YEARS. If you treat every bug report on here like
an idiot wrote it, only idiots are going to stick around to report
"bugs" for you. Spend a little more than 15 seconds on it.
I gave exact details and the simplest repro on earth, not to mention
the results of possible contributing factors. What else could you
possibly want. Why is it so hard to get problems even acknowledged
here? Maybe I should just mark them as bogus in the beginning to save
a little time. This is as bad as reporting bugs to Microsoft.
[2002-12-29 14:08:46] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
I think this is not a bug, but simply an issue of running out of
memory, because the data in the buffer simply gets too big. flush()
dumps the data inside the buffer to screen and clears the buffer, which
is why it wouldn't crash when flush() is used.
[2002-12-29 12:01:41] [EMAIL PROTECTED]
Setting implicit_flush to ON does not fix it - so maybe adding flush()
only helps because it slows it down..?
Also, messing with output_buffering has no effect.
This problem has been present ever since I started using PHP. Maybe a
memory overflow?
Can anyone else repro? (note this only happens with the sapi/mod
version)
[2002-12-29 00:05:14] [EMAIL PROTECTED]
On the SAPI version of php in Apache under WinXP:
for($Loop=0 ; $Loop<10 ; $Loop++)
{
echo "blah $Loop ";
}
(usually) causes IE to abort loading and reload the page many times;
eventually it just shows the standard "The page cannot be displayed",
"Cannot find server or DNS Error".
Netscape simply aborts in the middle, usually around 50,000. But,
sometimes it works fine.
If you add a flush() in the loop, the problem goes away.
Nothing shows up in the PHP or server error logs, so I assume its a
crash.
--
Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Bgs->Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 4.3.0
New Comment:
Then maybe this should be a doc change: "If you don't call flush() once
in a while, PHP will hang. This is not a bug. Hanging is
intentional."
This is a BUG. If it causes PHP to HANG before outputting the page,
then it is a BUG! FLUSH IS NOT SUPPOSED TO BE MANDATORY.
This also happens when outputting pages under 20K, but this example is
the best way to repro. And as I stated, implicit flushing does not fix
the problem either. Any delay in the loop fixes it.
Every time I submit something here, somebody spends 15 seconds on it
and marks it as bogus. When it is NOT. I WENT TO THE TIME OF
SUBMITTING THIS FOR A REASON, AND I AM NOT A JACKASS. I HAVE BEEN
PROGRAMMING FOR 15 YEARS. If you treat every bug report on here like
an idiot wrote it, only idiots are going to stick around to report
"bugs" for you. Spend a little more than 15 seconds on it.
I gave exact details and the simplest repro on earth, not to mention
the results of possible contributing factors. What else could you
possibly want. Why is it so hard to get problems even acknowledged
here? Maybe I should just mark them as bogus in the beginning to save
a little time. This is as bad as reporting bugs to Microsoft.
Previous Comments:
[2002-12-29 14:08:46] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
I think this is not a bug, but simply an issue of running out of
memory, because the data in the buffer simply gets too big. flush()
dumps the data inside the buffer to screen and clears the buffer, which
is why it wouldn't crash when flush() is used.
[2002-12-29 12:01:41] [EMAIL PROTECTED]
Setting implicit_flush to ON does not fix it - so maybe adding flush()
only helps because it slows it down..?
Also, messing with output_buffering has no effect.
This problem has been present ever since I started using PHP. Maybe a
memory overflow?
Can anyone else repro? (note this only happens with the sapi/mod
version)
[2002-12-29 00:05:14] [EMAIL PROTECTED]
On the SAPI version of php in Apache under WinXP:
for($Loop=0 ; $Loop<10 ; $Loop++)
{
echo "blah $Loop ";
}
(usually) causes IE to abort loading and reload the page many times;
eventually it just shows the standard "The page cannot be displayed",
"Cannot find server or DNS Error".
Netscape simply aborts in the middle, usually around 50,000. But,
sometimes it works fine.
If you add a flush() in the loop, the problem goes away.
Nothing shows up in the PHP or server error logs, so I assume its a
crash.
--
Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [Com]: crash or fail when outputting large amounts of text quickly
ID: 21262
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 4.3.0
New Comment:
Setting implicit_flush to ON does not fix it - so maybe adding flush()
only helps because it slows it down..?
Also, messing with output_buffering has no effect.
This problem has been present ever since I started using PHP. Maybe a
memory overflow?
Can anyone else repro? (note this only happens with the sapi/mod
version)
Previous Comments:
[2002-12-29 00:05:14] [EMAIL PROTECTED]
On the SAPI version of php in Apache under WinXP:
for($Loop=0 ; $Loop<10 ; $Loop++)
{
echo "blah $Loop ";
}
(usually) causes IE to abort loading and reload the page many times;
eventually it just shows the standard "The page cannot be displayed",
"Cannot find server or DNS Error".
Netscape simply aborts in the middle, usually around 50,000. But,
sometimes it works fine.
If you add a flush() in the loop, the problem goes away.
Nothing shows up in the PHP or server error logs, so I assume its a
crash.
--
Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21262 [NEW]: crash or fail when outputting large amounts of text quickly
From: [EMAIL PROTECTED]
Operating system: WinXP
PHP version: 4.3.0
PHP Bug Type: Reproducible crash
Bug description: crash or fail when outputting large amounts of text quickly
On the SAPI version of php in Apache under WinXP:
for($Loop=0 ; $Loop<10 ; $Loop++)
{
echo "blah $Loop ";
}
(usually) causes IE to abort loading and reload the page many times;
eventually it just shows the standard "The page cannot be displayed",
"Cannot find server or DNS Error".
Netscape simply aborts in the middle, usually around 50,000. But,
sometimes it works fine.
If you add a flush() in the loop, the problem goes away.
Nothing shows up in the PHP or server error logs, so I assume its a crash.
--
Edit bug report at http://bugs.php.net/?id=21262&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21262&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21262&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21262&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21262&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21262&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21262&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21262&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21262&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21262&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21262&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21262&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21262&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21262&r=isapi
