#20449 [Com]: sessions randomly fail
ID: 20449
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
interesting.
However, I switched my session manager to a dbase function and it still
died. How would file locking effect that?
I'm interested in the fact though that you can actually witness the bug
first hand. I only saw that it was happening. However, I could never
get the thing to happen to me.
Also, since I have gone to my own session code without using php's
built in sessions, I don't have problems at all anymore.
Josh
Previous Comments:
[2003-01-08 01:19:06] [EMAIL PROTECTED]
My script will fail in as short as 1 request or over 1000 requests.
I did set session.gc_probability = 0 but still fails.
-Ryan
[2003-01-08 01:13:53] [EMAIL PROTECTED]
I CAN REPRODUCE THIS BUG!!!
Sort of
I too had my software working perfectly for over a year under PHP 4.0.6
/ Apache 1.3.24 on Win2000 Pro (development) Win2000 Server
(production).
After upgrading to PHP 4.2.3 / Apache 1.3.27 I've been pulling my hair
out with this session disappearing problem. I tried just about
everything I could find in the bug lists mentioned in this bug to no
avail, short of trying latest CVS. I'm short on time and resources and
from what I read; they haven't fixed the problem yet.
As far as it being a serialization problem I don't think so. None of
my session variables are more complex than a string. So I wrote a
simple test and I know it's not IE specific. I could recreate the
problem with IE 6, Opera 6.05, Netscape 7.0, and Mozilla 1.3
I striped the test to be as simple as 1 integer as a session variable
and it would still die.
I removed the counting aspect to verify it wasn't a write problem, just
reading session data would kill it as well.
The error seems to occur if requests are made to the session variable
from different files close enough together in time to cause one to
"lock" the session file while the next request tries to access it.
Resulting in this error:
Warning: open(c:\tmp\sess_c6bdd642a5d88639e785ec13b0d2f126, O_RDWR)
failed: Permission denied (13) in c:\apache\htdocs\testing\session2.php
on line 10
Obviously it DOES have permission or else my scripts would fail all the
time.
This does fail on all Windows servers I tested with PHP 4.2.3. I did
try it on a Slackware 8.1 with PHP 4.2.1 / Apache 1.3.24 and it did NOT
fail.
I hope this helps track down the elusive bug so I don't have to
downgrade back to 4.0.6 but I'm left with few options.
I will try a CVS if you think it might fix it but I've already spent
more time than I have on this. And from what I read, they don't fix
it. If you need more info just ask. I'll try to do what I can.
My test consists of 4 files. Obviously the comments are not part of
the files.
//file: session0.php
// Just used to clean things up when they get ugly.
//---
Session Test
Load Values
//file: session1.php
// Sets up the session vars
//---
Session Test
Reset
Start Test in single page
Start Test in frames
//file: session2.php
// Calls itself repeatedly, increments count
//---
Session Test
<!--
alert("Session LOST!");
-->
Running...
0)) { ?>
<!--
setTimeout("document.location.href='session2.php'", 0);
-->
Session LOST!
//-file: sessionFrames.php --
// Defines the frameset
//---
Session Test
This page uses frames, but your browser doesn't support
them.
[2002-12-12 03:58:54] [EMAIL PROTECTED]
After upgrading to PHP 4.2.3, I'm having the same problem with random
session dataloss. Everything worked just fine before when using 4.0.6.
I'm using linux kernel 2.4.9 on an Intel machine, PHP 4.2.3/Apache
1.3.27. Session data files are stored on a NFS share, standard "files"
handler.
[2002-12-10 09:36:08] [EMAIL PROTECTED]
Upgraded to 4.4.0-dev and I'm still not dancing.
- php.ini settings are the same.
- URL's are not re-written.
- Session data lossage is almost
#21725 [NEW]: return behaviour differs between include and require
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.3.0
PHP Bug Type: Scripting Engine problem
Bug description: return behaviour differs between include and require
when a return is made out of an included file (using
include), the value is properly returned. However, using
the require statement instead results in values not being
preperly returned from a return statement in included
code.
Example
This function currently exists in a class and works.
function execQuery( &$sql, $result_status, $file, $line )
{
return include( dirname( __FILE__
)."/execQuery.php" );
}
This function DOES NOT WORK when I attempt the use the
result it is not defined.
function execQuery( &$sql, $result_status, $file, $line )
{
return require( dirname( __FILE__
)."/execQuery.php" );
}
This is the contents of the file it includes
validateFileConstants( $file,
$line, __FILE__, __LINE__ );
if ( !is_string( $sql ) ) {
$this->{$this->log_func} ( "File: $file. Line:
$line. \$sql is NOT a string. (%s, %d)",__FILE__, __LINE__
);
}
if ( !is_int( $result_status ) ) {
$this->{$this->log_func} ( "File: $file. Line:
$line. \$sql is NOT a string. (%s, %d)", __FILE__,
__LINE__ );
}
if ( $this->conn == NULL ) {
$this->{$this->log_func} ( "File: $file. Line:
$line. \$conn not open. (%s, %d)", __FILE__, __LINE__ );
}
if ( pg_result_status( $rs = pg_query ( $this->conn,
$sql ) ) !== $result_status ) {
/*pg_query returns false, can't use result_error.*/
$this->{$this->log_func} ( "File: $file. Line:
$line. Error executing. \"%s\" (%s, %d)"
, pg_last_error(), __FILE__,
__LINE__ );
}
return $rs;
?>
This behavious is also inconsistent with tjhe document
which reads that the onyl difference if a warning or Fatal
Error.
Josh.
--
Edit bug report at http://bugs.php.net/?id=21725&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21725&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21725&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21725&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21725&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21725&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21725&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21725&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21725&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21725&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21725&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21725&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21725&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21725&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21725&r=gnused
#20449 [NEW]: sessions randomly fail
to me would be a nightmare. It is possible that sharing the load on 2 servers will solve my problem. But I shouldn't have to have a second server when one server is perfectly capable of handling the traffic. (my server load hovers between 0 and 2.) My install options are: ./configure --with-apxs=/usr/sbin/apxs --with-config-file-path=/usr/local/lib --disable-debug --with-mysql=/usr I have apache 1.3.23 Here is a link to my phpinfo() function http://www.t-shirtking.com/temp/phpinfo.php Thanks, Josh Bauguss -- Edit bug report at http://bugs.php.net/?id=20449&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20449&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20449&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20449&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20449&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20449&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20449&r=support Expected behavior: http://bugs.php.net/fix.php?id=20449&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20449&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20449&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20449&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20449&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20449&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20449&r=isapi
#20449 [Csd->Opn]: sessions randomly fail
It also happens at any time during the day (meaning, high traffic times and low traffic times) I have also been able to immediately look at my sessions table in the database when I receive a message like the above. Sure enough, the session is there...it has data...just no cart. Of course, the biggest problem of allI can't reproduce the bug to save my life. I've tested on 10 different machines using a variety of Windows versions and IE versions. I've tested the cart well over 100 times. Yet, I never seem to be able to break it. I even try to add the product that I know the person who did lose the cart was trying to buy. I'm pretty sure I'm losing orders because of this. I can't imagine how many people are having issues. I have tried two things in the last couple of days. One, I downloaded and installed the cvs version of PHP. I also stopped storing the cart as an object and simply storing it as an array. Neither of these tests have worked. I still get the problem. Right now, we are going to setup a second server and split the traffic among each. Hopefully this will lower the loss of session data. The other wierd thing is that I don't lose the entire session. Just the part that contains the cart array. (and before that the cart object) Remember, the cart object had the same array in it that I am storing now. Perhaps the problem is with storing arrays??? Anyway, this is a major problem. I've seen it in past bug reports. The fact is, sessions are unreliable. And that is a shame. I see it as mission critical for PHP. If this doesn't get fixed soon, I guarantee that my client will want to move away from php. And that to me would be a nightmare. It is possible that sharing the load on 2 servers will solve my problem. But I shouldn't have to have a second server when one server is perfectly capable of handling the traffic. (my server load hovers between 0 and 2.) My install options are: ./configure --with-apxs=/usr/sbin/apxs --with-config-file-path=/usr/local/lib --disable-debug --with-mysql=/usr I have apache 1.3.23 Here is a link to my phpinfo() function http://www.t-shirtking.com/temp/phpinfo.php Thanks, Josh Bauguss -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
recently switched it to a mysql based manager. (just using the session_save_handler). I still get the issue though. Therefore, I cancel out blaming php's file storage method. Where is my cart object going? It happens only randomly. It also happens only to users of IE. (though 90% of our traffic are IE users) It happens to IE6.0, IE5.5, IE5.0. It also happens at any time during the day (meaning, high traffic times and low traffic times) I have also been able to immediately look at my sessions table in the database when I receive a message like the above. Sure enough, the session is there...it has data...just no cart. Of course, the biggest problem of allI can't reproduce the bug to save my life. I've tested on 10 different machines using a variety of Windows versions and IE versions. I've tested the cart well over 100 times. Yet, I never seem to be able to break it. I even try to add the product that I know the person who did lose the cart was trying to buy. I'm pretty sure I'm losing orders because of this. I can't imagine how many people are having issues. I have tried two things in the last couple of days. One, I downloaded and installed the cvs version of PHP. I also stopped storing the cart as an object and simply storing it as an array. Neither of these tests have worked. I still get the problem. Right now, we are going to setup a second server and split the traffic among each. Hopefully this will lower the loss of session data. The other wierd thing is that I don't lose the entire session. Just the part that contains the cart array. (and before that the cart object) Remember, the cart object had the same array in it that I am storing now. Perhaps the problem is with storing arrays??? Anyway, this is a major problem. I've seen it in past bug reports. The fact is, sessions are unreliable. And that is a shame. I see it as mission critical for PHP. If this doesn't get fixed soon, I guarantee that my client will want to move away from php. And that to me would be a nightmare. It is possible that sharing the load on 2 servers will solve my problem. But I shouldn't have to have a second server when one server is perfectly capable of handling the traffic. (my server load hovers between 0 and 2.) My install options are: ./configure --with-apxs=/usr/sbin/apxs --with-config-file-path=/usr/local/lib --disable-debug --with-mysql=/usr I have apache 1.3.23 Here is a link to my phpinfo() function http://www.t-shirtking.com/temp/phpinfo.php Thanks, Josh Bauguss -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: The php version I'm using at the moment is PHP Version 4.4.0-dev Any other info can be found here. http://www.t-shirtking.com/temp/phpinfo.php Previous Comments: [2002-11-15 19:32:38] [EMAIL PROTECTED] Can you add _short_ example script here that shows the problem, as I'm using sessions a lot and never have had any problems with them. Albeit I haven't tried to overload them too much either. Maybe you're doing something that isn't really been thought about when the session extension was written? [2002-11-15 19:26:09] [EMAIL PROTECTED] Please put correct version number in the report.. I assume it's 4.3.0-dev but if it's something else, please change it. [2002-11-15 16:35:46] [EMAIL PROTECTED] I've experienced the same problem, on various platforms. SPARC Solaris 8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha Linux 2.4 with PHP 4.2.3. However I'm not using it in the context of a shopping cart, my application is that of a "Checksheet" that we use to mark off Quality Assurance items. The Checksheet is large so I store the form contents in a session. They can move through all kinds of menus and parts of the Checksheet and the work is stored entirely in a session. About 8 people use this Checksheet system throughout the day 7 days a week, about once a day suddenly the Checksheet system will say they aren't logged in, and when they relogin in, their work is gone. I've implemented a quick and dirty save to database feature for long term storage and I've encouraged my users to frequently save. The save merely serializes the Checksheet object that is normally stored in a session, and saves it to a database. [2002-11-15 14:15:51] [EMAIL PROTECTED] Quick question. What should session.save_handler be in the php.ini file when using my own mysql session handlers? Should it remain files or should it get set to user to make the session_set_save_handler work properly? The documentation is somewhat unclear on this. [2002-11-15 13:58:51] [EMAIL PROTECTED] I am already using the save handler to use my own mysql backend. Please don't close this bug again. I am using CVS from a build on 11-14-2002. I still get random session failure. Here is a list of other bugs that are related to this. Bug #19029 Bug #17846 Bug #19972 Bug #19022 As far as I can tell, these other bugs were never fully resolved. BTW, while I allow php to set a cookie, I don't use it at all. I manually set session_id by using the session passed via the url. 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: As for an example script...I don't think I could make it short. However, the script is only a shopping cart. I'm not doing anything out of the ordinary. It is a simple array of strings. I try to store the array as a session. Like I said before, I've never been able to break it myself. However, I do see evidence of it breaking. (ie. the e-mail that is sent to me) I guess it should be possible to write a script that continuously tries to add to cart then checkout and see if it would break that way. I will do so and get back to you. In the meantime, I will change the status of this to feedback. Previous Comments: [2002-11-16 19:55:52] [EMAIL PROTECTED] The php version I'm using at the moment is PHP Version 4.4.0-dev Any other info can be found here. http://www.t-shirtking.com/temp/phpinfo.php [2002-11-15 19:32:38] [EMAIL PROTECTED] Can you add _short_ example script here that shows the problem, as I'm using sessions a lot and never have had any problems with them. Albeit I haven't tried to overload them too much either. Maybe you're doing something that isn't really been thought about when the session extension was written? [2002-11-15 19:26:09] [EMAIL PROTECTED] Please put correct version number in the report.. I assume it's 4.3.0-dev but if it's something else, please change it. [2002-11-15 16:35:46] [EMAIL PROTECTED] I've experienced the same problem, on various platforms. SPARC Solaris 8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha Linux 2.4 with PHP 4.2.3. However I'm not using it in the context of a shopping cart, my application is that of a "Checksheet" that we use to mark off Quality Assurance items. The Checksheet is large so I store the form contents in a session. They can move through all kinds of menus and parts of the Checksheet and the work is stored entirely in a session. About 8 people use this Checksheet system throughout the day 7 days a week, about once a day suddenly the Checksheet system will say they aren't logged in, and when they relogin in, their work is gone. I've implemented a quick and dirty save to database feature for long term storage and I've encouraged my users to frequently save. The save merely serializes the Checksheet object that is normally stored in a session, and saves it to a database. [2002-11-15 14:15:51] [EMAIL PROTECTED] Quick question. What should session.save_handler be in the php.ini file when using my own mysql session handlers? Should it remain files or should it get set to user to make the session_set_save_handler work properly? The documentation is somewhat unclear on this. 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: Ok, I can only open or close this. If you'd like, change it to feedback. I will provide more details soon. I'm very anxious to help squash this problem. Previous Comments: [2002-11-16 20:32:11] [EMAIL PROTECTED] As for an example script...I don't think I could make it short. However, the script is only a shopping cart. I'm not doing anything out of the ordinary. It is a simple array of strings. I try to store the array as a session. Like I said before, I've never been able to break it myself. However, I do see evidence of it breaking. (ie. the e-mail that is sent to me) I guess it should be possible to write a script that continuously tries to add to cart then checkout and see if it would break that way. I will do so and get back to you. In the meantime, I will change the status of this to feedback. [2002-11-16 19:55:52] [EMAIL PROTECTED] The php version I'm using at the moment is PHP Version 4.4.0-dev Any other info can be found here. http://www.t-shirtking.com/temp/phpinfo.php [2002-11-15 19:32:38] [EMAIL PROTECTED] Can you add _short_ example script here that shows the problem, as I'm using sessions a lot and never have had any problems with them. Albeit I haven't tried to overload them too much either. Maybe you're doing something that isn't really been thought about when the session extension was written? [2002-11-15 19:26:09] [EMAIL PROTECTED] Please put correct version number in the report.. I assume it's 4.3.0-dev but if it's something else, please change it. [2002-11-15 16:35:46] [EMAIL PROTECTED] I've experienced the same problem, on various platforms. SPARC Solaris 8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha Linux 2.4 with PHP 4.2.3. However I'm not using it in the context of a shopping cart, my application is that of a "Checksheet" that we use to mark off Quality Assurance items. The Checksheet is large so I store the form contents in a session. They can move through all kinds of menus and parts of the Checksheet and the work is stored entirely in a session. About 8 people use this Checksheet system throughout the day 7 days a week, about once a day suddenly the Checksheet system will say they aren't logged in, and when they relogin in, their work is gone. I've implemented a quick and dirty save to database feature for long term storage and I've encouraged my users to frequently save. The save merely serializes the Checksheet object that is normally stored in a session, and saves it to a database. 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: ok. This is really frustrating. I wrote a script that simulates a cart. I use fopen once to add something to the cart, and a second time to check the cart. (I use uniqid to create a session id and pass it through the url) The script simulates it 100 times. Then, via a interface and iframes, I have six frames loading the test script. See - http://www.t-shirtking.com/temp/testcart.html This raises the load a little. However, as you will see, it checks out everytime. However, this morning I check my e-mail and find a dozen more messages from the order page that tells me someones cart was empty. Next message, I'm gonna show you my cart. It isn't too complicated. Previous Comments: [2002-11-17 11:07:55] [EMAIL PROTECTED] I too can't reproduce this bug. Someones when someone uses the Checksheet system the session dies after 15 minutes. I run back and we repeat every step the person did leading up to the session that disappears. Wait 15 minutes, do exactly the same thing, but this time it works. Other times people leave it idle for 2 hours at a time and it disappears, and sometimes it doesn't. But I have my sessions set not to timeout, only after browser closes. I haven't been doing anything special. After the session 'disppears' I log onto the server and look at the session save path directory for the session (in an attempt to recover the data stored in it), and it's no longer there. I'll continue to try and reproduce this bug and if I find anything I'll post here. [2002-11-16 20:33:38] [EMAIL PROTECTED] Ok, I can only open or close this. If you'd like, change it to feedback. I will provide more details soon. I'm very anxious to help squash this problem. [2002-11-16 20:32:11] [EMAIL PROTECTED] As for an example script...I don't think I could make it short. However, the script is only a shopping cart. I'm not doing anything out of the ordinary. It is a simple array of strings. I try to store the array as a session. Like I said before, I've never been able to break it myself. However, I do see evidence of it breaking. (ie. the e-mail that is sent to me) I guess it should be possible to write a script that continuously tries to add to cart then checkout and see if it would break that way. I will do so and get back to you. In the meantime, I will change the status of this to feedback. [2002-11-16 19:55:52] [EMAIL PROTECTED] The php version I'm using at the moment is PHP Version 4.4.0-dev Any other info can be found here. http://www.t-shirtking.com/temp/phpinfo.php [2002-11-15 19:32:38] [EMAIL PROTECTED] Can you add _short_ example script here that shows the problem, as I'm using sessions a lot and never have had any problems with them. Albeit I haven't tried to overload them too much either. Maybe you're doing something that isn't really been thought about when the session extension was written? 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: Here is my cart script. The only special thing I do before this is to initiate the session. I always call session_id(an id) before session_start because I can't rely on cookies. The only time I do not call session_id is when the visitor first comes to the site. manage_products() is called on the cart.php page when a user either adds an item or updates an item. Also, cart.php is the only page that manipulates the cart. Every other page simply display cart info. (including the order page) Previous Comments: [2002-11-17 12:06:13] [EMAIL PROTECTED] ok. This is really frustrating. I wrote a script that simulates a cart. I use fopen once to add something to the cart, and a second time to check the cart. (I use uniqid to create a session id and pass it through the url) The script simulates it 100 times. Then, via a interface and iframes, I have six frames loading the test script. See - http://www.t-shirtking.com/temp/testcart.html This raises the load a little. However, as you will see, it checks out everytime. However, this morning I check my e-mail and find a dozen more messages from the order page that tells me someones cart was empty. Next message, I'm gonna show you my cart. It isn't too complicated. [2002-11-17 11:07:55] [EMAIL PROTECTED] I too can't reproduce this bug. Someones when someone uses the Checksheet system the session dies after 15 minutes. I run back and we repeat every step the person did leading up to the session that disappears. Wait 15 minutes, do exactly the same thing, but this time it works. Other times people leave it idle for 2 hours at a time and it disappears, and sometimes it doesn't. But I have my sessions set not to timeout, only after browser closes. I haven't been doing anything special. After the session 'disppears' I log onto the server and look at the session save path directory for the session (in an attempt to recover the data stored in it), and it's no longer there. I'll continue to try and reproduce this bug and if I find anything I'll post here. [2002-11-16 20:33:38] [EMAIL PROTECTED] Ok, I can only open or close this. If you'd like, change it to feedback. I will provide more details soon. I'm very anxious to help squash this problem. [2002-11-16 20:32:11] [EMAIL PROTECTED] As for an example script...I don't think I could make it short. However, the script is only a shopping cart. I'm not doing anything out of the ordinary. It is a simple array of strings. I try to store the array as a session. Like I said before, I've never been able to break it myself. However, I do see evidence of it breaking. (ie. the e-mail that is sent to me) I guess it should be possible to write a script that continuously tries to add to cart then checkout and see if it would break that way. I will do so and get back to you. In the meantime, I will change the status of this to feedback. [2002-11-16 19:55:52] [EMAIL PROTECTED] The php version I'm using at the moment is PHP Version 4.4.0-dev Any other info can be found here. http://www.t-shirtking.com/temp/phpinfo.php 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.3.0-dev
New Comment:
here is my session save handler. Pretty much taken from phpbuilder.com
article.
Important to note that I have never seen a mysql error in my php_errors
log.
Can't connect to " . $GLOBALS["SESS_DBHOST"] . " as "
. $GLOBALS["SESS_DBUSER"];
echo "MySQL Error: ", mysql_error();
die;
}
if (! mysql_select_db($GLOBALS["SESS_DBNAME"],
$GLOBALS["SESS_DBH"]))
{
echo "Unable to select database " .
$GLOBALS["SESS_DBNAME"];
die;
}
return true;
}
function sess_close()
{
return true;
}
function sess_read($key)
{
$qry = "SELECT value FROM sessions WHERE sesskey = '$key' AND
expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (list($value) = mysql_fetch_row($qid))
{
return $value;
}
return "";
}
function sess_write($key, $val)
{
$expiry = time() + $GLOBALS["SESS_LIFE"];
$value = addslashes($val);
$qry = "INSERT INTO sessions VALUES ('$key', $expiry, '$value')";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (! $qid)
{
$qry = "UPDATE sessions SET expiry = $expiry, value = '$value'
WHERE sesskey = '$key' AND expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
}
return $qid;
}
function sess_destroy($key)
{
$qry = "DELETE FROM sessions WHERE sesskey = '$key'";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return $qid;
}
function sess_gc($maxlifetime)
{
$qry = "DELETE FROM sessions WHERE expiry < " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return mysql_affected_rows($GLOBALS["SESS_DBH"]);
}
//now that we have defined everything, set the save handler
session_set_save_handler(
"sess_open",
"sess_close",
"sess_read",
"sess_write",
"sess_destroy",
"sess_gc");
?>
Previous Comments:
[2002-11-17 12:13:59] [EMAIL PROTECTED]
Here is my cart script.
The only special thing I do before this is to initiate the session. I
always call session_id(an id) before session_start because I can't rely
on cookies. The only time I do not call session_id is when the visitor
first comes to the site.
manage_products() is called on the cart.php page when a user either
adds an item or updates an item.
Also, cart.php is the only page that manipulates the cart. Every other
page simply display cart info. (including the order page)
[2002-11-17 12:06:13] [EMAIL PROTECTED]
ok. This is really frustrating. I wrote a script that simulates a
cart. I use fopen once to add something to the cart, and a second time
to check the cart. (I use uniqid to create a session id and pass it
through the url)
The script simulates it 100 times. Then, via a interface and iframes,
I have six frames loading the test script.
See - http://www.t-shirtking.com/temp/testcart.html
This raises the load a little. However, as you will see, it checks out
everytime.
However, this morning I check my e-mail and find a dozen more messages
from the order page that tells me someones cart was empty.
Next message, I'm gonna show you my cart. It isn't too complicated.
[2002-11-17 11:07:55] [EMAIL PROTECTED]
I too can't reproduce this bug. Someones when someone uses the
Checksheet system the session dies after 15 minutes. I run back and we
repeat every step the person did leading up to the session that
disappears. Wait 15 minutes, do exactly the same thing, but this time
it works. Other times people leave it idle for 2 hours at a time and it
disappears, and sometimes it doesn't. But I have my sessions set not to
timeout, only after browser closes. I haven't been doing anything
special. After the session 'disppears' I log onto the server and look
at the session save path directory for the session (in an attempt to
recover the data stored in it), and it's no longer there. I'll continue
to try and reproduce this bug and if I find anything I'll post here.
[2002-11-16 20:33:38] [EMAIL PROTECTED]
Ok, I can only open or close this. If you'd like, change it to
feedback. I will provide more details soon.
I'm very anxious to help squash this problem.
[2002-11-16 20:32:11] [EMAIL PROTECTED]
As for an example script...I don't think I could make it short.
However, the script is only a shopping cart. I'm
#20449 [Fbk->Opn]: sessions randomly fail
ID: 20449
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: redhat 7.3
-PHP Version: 4.3.0-dev
+PHP Version: 4.4.0-dev
New Comment:
I'm reopening this bug as I've provided more feedback.
Please yell at me if I'm not doing this right :)
Previous Comments:
[2002-11-17 12:17:39] [EMAIL PROTECTED]
here is my session save handler. Pretty much taken from phpbuilder.com
article.
Important to note that I have never seen a mysql error in my php_errors
log.
Can't connect to " . $GLOBALS["SESS_DBHOST"] . " as "
. $GLOBALS["SESS_DBUSER"];
echo "MySQL Error: ", mysql_error();
die;
}
if (! mysql_select_db($GLOBALS["SESS_DBNAME"],
$GLOBALS["SESS_DBH"]))
{
echo "Unable to select database " .
$GLOBALS["SESS_DBNAME"];
die;
}
return true;
}
function sess_close()
{
return true;
}
function sess_read($key)
{
$qry = "SELECT value FROM sessions WHERE sesskey = '$key' AND
expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (list($value) = mysql_fetch_row($qid))
{
return $value;
}
return "";
}
function sess_write($key, $val)
{
$expiry = time() + $GLOBALS["SESS_LIFE"];
$value = addslashes($val);
$qry = "INSERT INTO sessions VALUES ('$key', $expiry, '$value')";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (! $qid)
{
$qry = "UPDATE sessions SET expiry = $expiry, value = '$value'
WHERE sesskey = '$key' AND expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
}
return $qid;
}
function sess_destroy($key)
{
$qry = "DELETE FROM sessions WHERE sesskey = '$key'";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return $qid;
}
function sess_gc($maxlifetime)
{
$qry = "DELETE FROM sessions WHERE expiry < " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return mysql_affected_rows($GLOBALS["SESS_DBH"]);
}
//now that we have defined everything, set the save handler
session_set_save_handler(
"sess_open",
"sess_close",
"sess_read",
"sess_write",
"sess_destroy",
"sess_gc");
?>
[2002-11-17 12:13:59] [EMAIL PROTECTED]
Here is my cart script.
The only special thing I do before this is to initiate the session. I
always call session_id(an id) before session_start because I can't rely
on cookies. The only time I do not call session_id is when the visitor
first comes to the site.
manage_products() is called on the cart.php page when a user either
adds an item or updates an item.
Also, cart.php is the only page that manipulates the cart. Every other
page simply display cart info. (including the order page)
[2002-11-17 12:06:13] [EMAIL PROTECTED]
ok. This is really frustrating. I wrote a script that simulates a
cart. I use fopen once to add something to the cart, and a second time
to check the cart. (I use uniqid to create a session id and pass it
through the url)
The script simulates it 100 times. Then, via a interface and iframes,
I have six frames loading the test script.
See - http://www.t-shirtking.com/temp/testcart.html
This raises the load a little. However, as you will see, it checks out
everytime.
However, this morning I check my e-mail and find a dozen more messages
from the order page that tells me someones cart was empty.
Next message, I'm gonna show you my cart. It isn't too complicated.
[2002-11-17 11:07:55] [EMAIL PROTECTED]
I too can't reproduce this bug. Someones when someone uses the
Checksheet system the session dies after 15 minutes. I run back and we
repeat every step the person did leading up to the session that
disappears. Wait 15 minutes, do exactly the same thing, but this time
it works. Other times people leave it idle for 2 hours at a time and it
disappears, and sometimes it doesn't. But I have my sessions set not to
timeout, only after browser closes. I haven't been doing anything
special. After the session 'disppears' I log onto the server and look
at the session save path directory for the session (in an attempt to
recover the data stored in it), and it's no longer there. I'll continue
to try and reproduce this bug and if I find anything I'll post here.
[2002-11-16 20:33:38] [EMAIL PROTECTED]
Ok, I can only open or close this. If you'd like, change it to
feedback. I will provide more details soon.
#20449 [Com]: sessions randomly fail
ID: 20449
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
I'm trying to provide as much as I can.
Here is a sample session from the dbase.
cart|a:1:{s:9:"161-00084";s:14:"White-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
A quick thought. I use the | as a delimiter to seperate the color-size
and quantity. Would my delimiter potentially screw up the unserialize
or serialize functions?
For multiple products here is a sample session.
cart|a:2:{s:9:"117-00717";s:20:"Black-Small_Medium|1";s:9:"117-00875";s:15:"Yellow-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
Previous Comments:
[2002-11-17 12:36:34] [EMAIL PROTECTED]
Missed a couple of words in the above. "will randomly be deleted" I
meant to write.
[2002-11-17 12:35:37] [EMAIL PROTECTED]
Your handler isn't very good. As far as I can tell you never update
the expiry value which means that your sessions will randomly (because
the gc hook is called on a probability) after 5400 seconds (90 minutes)
after initial creation. A quick fix would be to never expire sessions
by setting:
session.gc_probability = 0
In your php.ini file. Or, better yet, fix your handler to update the
expiry time when writing to a session. This expiry time is supposed to
be idle session time, not an absolute the way you have it.
I would suggest letting MySQL handle the timestamp and using a schema
that looks like this:
id char(32) NOT NULL,
data text,
ts timestamp,
PRIMARY KEY (id)
And instead of that ugly INSERT/UPDATE thing you have for your write
hook, use:
$data = addslashes($data);
mysql_query("replace into $table (id,data) values('$id','$data')")
or error_log("write:
".mysql_error()."\n",3,"/tmp/errors.log");
The gc hook would just be:
function gc($max_time) {
global $table;
mysql_query(
"delete from $table where
UNIX_TIMESTAMP(ts)Can't connect to " . $GLOBALS["SESS_DBHOST"] . " as "
. $GLOBALS["SESS_DBUSER"];
echo "MySQL Error: ", mysql_error();
die;
}
if (! mysql_select_db($GLOBALS["SESS_DBNAME"],
$GLOBALS["SESS_DBH"]))
{
echo "Unable to select database " .
$GLOBALS["SESS_DBNAME"];
die;
}
return true;
}
function sess_close()
{
return true;
}
function sess_read($key)
{
$qry = "SELECT value FROM sessions WHERE sesskey = '$key' AND
expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (list($value) = mysql_fetch_row($qid))
{
return $value;
}
return "";
}
function sess_write($key, $val)
{
$expiry = time() + $GLOBALS["SESS_LIFE"];
$value = addslashes($val);
$qry = "INSERT INTO sessions VALUES ('$key', $expiry, '$value')";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (! $qid)
{
$qry = "UPDATE sessions SET expiry = $expiry, value = '$value'
WHERE sesskey = '$key' AND expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
}
return $qid;
}
function sess_destroy($key)
{
$qry = "DELETE FROM sessions WHERE sesskey = '$key'";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return $qid;
}
function sess_gc($maxlifetime)
{
$qry = "DELETE FROM sessions WHERE expiry < " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return mysql_affected_rows($GLOBALS["SESS_DBH"]);
}
//now that we have defined everything, set the save handler
session_set_save_handler(
"sess_open",
"sess_close",
"sess_read",
"sess_write",
"sess_destroy",
"sess_gc");
?>
[2002-11-17 12:13:59] [EMAIL PROTECTED]
Here is my cart script.
The only special thing I do before this is to initiate the session. I
always call session_id(an id) before session_start because I can't rely
on cookies. The only time I do not call session_id is when the visitor
first comes to the site.
manage_products() is called on the cart.php page when a user either
adds an item or updates an item.
Also, cart.php is the only page that manipulates the cart. Every other
page simply display cart info. (including the order page)
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/20449
--
Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
Ok. I will fix my handler using your suggestions. I'll get back to
you after a few hours of letting it work.
Josh
Previous Comments:
[2002-11-17 12:40:32] [EMAIL PROTECTED]
I'm trying to provide as much as I can.
Here is a sample session from the dbase.
cart|a:1:{s:9:"161-00084";s:14:"White-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
A quick thought. I use the | as a delimiter to seperate the color-size
and quantity. Would my delimiter potentially screw up the unserialize
or serialize functions?
For multiple products here is a sample session.
cart|a:2:{s:9:"117-00717";s:20:"Black-Small_Medium|1";s:9:"117-00875";s:15:"Yellow-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
[2002-11-17 12:36:34] [EMAIL PROTECTED]
Missed a couple of words in the above. "will randomly be deleted" I
meant to write.
[2002-11-17 12:35:37] [EMAIL PROTECTED]
Your handler isn't very good. As far as I can tell you never update
the expiry value which means that your sessions will randomly (because
the gc hook is called on a probability) after 5400 seconds (90 minutes)
after initial creation. A quick fix would be to never expire sessions
by setting:
session.gc_probability = 0
In your php.ini file. Or, better yet, fix your handler to update the
expiry time when writing to a session. This expiry time is supposed to
be idle session time, not an absolute the way you have it.
I would suggest letting MySQL handle the timestamp and using a schema
that looks like this:
id char(32) NOT NULL,
data text,
ts timestamp,
PRIMARY KEY (id)
And instead of that ugly INSERT/UPDATE thing you have for your write
hook, use:
$data = addslashes($data);
mysql_query("replace into $table (id,data) values('$id','$data')")
or error_log("write:
".mysql_error()."\n",3,"/tmp/errors.log");
The gc hook would just be:
function gc($max_time) {
global $table;
mysql_query(
"delete from $table where
UNIX_TIMESTAMP(ts)Can't connect to " . $GLOBALS["SESS_DBHOST"] . " as "
. $GLOBALS["SESS_DBUSER"];
echo "MySQL Error: ", mysql_error();
die;
}
if (! mysql_select_db($GLOBALS["SESS_DBNAME"],
$GLOBALS["SESS_DBH"]))
{
echo "Unable to select database " .
$GLOBALS["SESS_DBNAME"];
die;
}
return true;
}
function sess_close()
{
return true;
}
function sess_read($key)
{
$qry = "SELECT value FROM sessions WHERE sesskey = '$key' AND
expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (list($value) = mysql_fetch_row($qid))
{
return $value;
}
return "";
}
function sess_write($key, $val)
{
$expiry = time() + $GLOBALS["SESS_LIFE"];
$value = addslashes($val);
$qry = "INSERT INTO sessions VALUES ('$key', $expiry, '$value')";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
if (! $qid)
{
$qry = "UPDATE sessions SET expiry = $expiry, value = '$value'
WHERE sesskey = '$key' AND expiry > " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
}
return $qid;
}
function sess_destroy($key)
{
$qry = "DELETE FROM sessions WHERE sesskey = '$key'";
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return $qid;
}
function sess_gc($maxlifetime)
{
$qry = "DELETE FROM sessions WHERE expiry < " . time();
$qid = mysql_query($qry, $GLOBALS["SESS_DBH"]);
return mysql_affected_rows($GLOBALS["SESS_DBH"]);
}
//now that we have defined everything, set the save handler
session_set_save_handler(
"sess_open",
"sess_close",
"sess_read",
"sess_write",
"sess_destroy",
"sess_gc");
?>
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/20449
--
Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Fbk->Opn]: sessions randomly fail
ID: 20449
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
I set the gc_probability to 0. After 5 hours, I got another dozen
notifications that the cart failed. I even got a tech support
complaint from a customer.
My hunch is that the serializer is obliterating the array. One of the
recent things I started to do was to initialize $_SESSION["cart"] =
Array(); when they first enter the site. On the sessions that have
problems, the cart variable disappears. However, other session
variables still exist.
No where on the site do I attempt to destroy the session.
I'm going to change my | delimiter as I notice that the serializer uses
a | as a delimiter. I wonder if that could be it. (though, it works
most of the time)
I've made the other changes to the handler. I still see problems
though. Is there any particular user behaviour that could explain it?
I had someone suggest to me that a user double clicking the add to cart
button could do it. I don't see how though. Not only that, I've tried
clicking more than once myself and have never seen the problem.
Josh
Previous Comments:
[2002-11-17 12:42:17] [EMAIL PROTECTED]
Ok. I will fix my handler using your suggestions. I'll get back to
you after a few hours of letting it work.
Josh
[2002-11-17 12:40:32] [EMAIL PROTECTED]
I'm trying to provide as much as I can.
Here is a sample session from the dbase.
cart|a:1:{s:9:"161-00084";s:14:"White-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
A quick thought. I use the | as a delimiter to seperate the color-size
and quantity. Would my delimiter potentially screw up the unserialize
or serialize functions?
For multiple products here is a sample session.
cart|a:2:{s:9:"117-00717";s:20:"Black-Small_Medium|1";s:9:"117-00875";s:15:"Yellow-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
[2002-11-17 12:36:34] [EMAIL PROTECTED]
Missed a couple of words in the above. "will randomly be deleted" I
meant to write.
[2002-11-17 12:35:37] [EMAIL PROTECTED]
Your handler isn't very good. As far as I can tell you never update
the expiry value which means that your sessions will randomly (because
the gc hook is called on a probability) after 5400 seconds (90 minutes)
after initial creation. A quick fix would be to never expire sessions
by setting:
session.gc_probability = 0
In your php.ini file. Or, better yet, fix your handler to update the
expiry time when writing to a session. This expiry time is supposed to
be idle session time, not an absolute the way you have it.
I would suggest letting MySQL handle the timestamp and using a schema
that looks like this:
id char(32) NOT NULL,
data text,
ts timestamp,
PRIMARY KEY (id)
And instead of that ugly INSERT/UPDATE thing you have for your write
hook, use:
$data = addslashes($data);
mysql_query("replace into $table (id,data) values('$id','$data')")
or error_log("write:
".mysql_error()."\n",3,"/tmp/errors.log");
The gc hook would just be:
function gc($max_time) {
global $table;
mysql_query(
"delete from $table where
UNIX_TIMESTAMP(ts)http://bugs.php.net/20449
--
Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
Changing my delimiter has not helped either.
This is really hard to reproduce. But it is happening. I don't know
if adding a second server to share the load will help or not. While we
will be adding a second server tomorrow, we really shouldn't have to.
What should I do next?
Josh
Previous Comments:
[2002-11-17 17:32:18] [EMAIL PROTECTED]
I set the gc_probability to 0. After 5 hours, I got another dozen
notifications that the cart failed. I even got a tech support
complaint from a customer.
My hunch is that the serializer is obliterating the array. One of the
recent things I started to do was to initialize $_SESSION["cart"] =
Array(); when they first enter the site. On the sessions that have
problems, the cart variable disappears. However, other session
variables still exist.
No where on the site do I attempt to destroy the session.
I'm going to change my | delimiter as I notice that the serializer uses
a | as a delimiter. I wonder if that could be it. (though, it works
most of the time)
I've made the other changes to the handler. I still see problems
though. Is there any particular user behaviour that could explain it?
I had someone suggest to me that a user double clicking the add to cart
button could do it. I don't see how though. Not only that, I've tried
clicking more than once myself and have never seen the problem.
Josh
[2002-11-17 12:42:17] [EMAIL PROTECTED]
Ok. I will fix my handler using your suggestions. I'll get back to
you after a few hours of letting it work.
Josh
[2002-11-17 12:40:32] [EMAIL PROTECTED]
I'm trying to provide as much as I can.
Here is a sample session from the dbase.
cart|a:1:{s:9:"161-00084";s:14:"White-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
A quick thought. I use the | as a delimiter to seperate the color-size
and quantity. Would my delimiter potentially screw up the unserialize
or serialize functions?
For multiple products here is a sample session.
cart|a:2:{s:9:"117-00717";s:20:"Black-Small_Medium|1";s:9:"117-00875";s:15:"Yellow-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
[2002-11-17 12:36:34] [EMAIL PROTECTED]
Missed a couple of words in the above. "will randomly be deleted" I
meant to write.
[2002-11-17 12:35:37] [EMAIL PROTECTED]
Your handler isn't very good. As far as I can tell you never update
the expiry value which means that your sessions will randomly (because
the gc hook is called on a probability) after 5400 seconds (90 minutes)
after initial creation. A quick fix would be to never expire sessions
by setting:
session.gc_probability = 0
In your php.ini file. Or, better yet, fix your handler to update the
expiry time when writing to a session. This expiry time is supposed to
be idle session time, not an absolute the way you have it.
I would suggest letting MySQL handle the timestamp and using a schema
that looks like this:
id char(32) NOT NULL,
data text,
ts timestamp,
PRIMARY KEY (id)
And instead of that ugly INSERT/UPDATE thing you have for your write
hook, use:
$data = addslashes($data);
mysql_query("replace into $table (id,data) values('$id','$data')")
or error_log("write:
".mysql_error()."\n",3,"/tmp/errors.log");
The gc hook would just be:
function gc($max_time) {
global $table;
mysql_query(
"delete from $table where
UNIX_TIMESTAMP(ts)http://bugs.php.net/20449
--
Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
I just noticed something in my session table.
a:2:{s:4:"cart";N;s:10:"gobackpage";N;}
What does N mean?
Previous Comments:
[2002-11-17 22:56:14] [EMAIL PROTECTED]
Changing my delimiter has not helped either.
This is really hard to reproduce. But it is happening. I don't know
if adding a second server to share the load will help or not. While we
will be adding a second server tomorrow, we really shouldn't have to.
What should I do next?
Josh
[2002-11-17 17:32:18] [EMAIL PROTECTED]
I set the gc_probability to 0. After 5 hours, I got another dozen
notifications that the cart failed. I even got a tech support
complaint from a customer.
My hunch is that the serializer is obliterating the array. One of the
recent things I started to do was to initialize $_SESSION["cart"] =
Array(); when they first enter the site. On the sessions that have
problems, the cart variable disappears. However, other session
variables still exist.
No where on the site do I attempt to destroy the session.
I'm going to change my | delimiter as I notice that the serializer uses
a | as a delimiter. I wonder if that could be it. (though, it works
most of the time)
I've made the other changes to the handler. I still see problems
though. Is there any particular user behaviour that could explain it?
I had someone suggest to me that a user double clicking the add to cart
button could do it. I don't see how though. Not only that, I've tried
clicking more than once myself and have never seen the problem.
Josh
[2002-11-17 12:42:17] [EMAIL PROTECTED]
Ok. I will fix my handler using your suggestions. I'll get back to
you after a few hours of letting it work.
Josh
[2002-11-17 12:40:32] [EMAIL PROTECTED]
I'm trying to provide as much as I can.
Here is a sample session from the dbase.
cart|a:1:{s:9:"161-00084";s:14:"White-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
A quick thought. I use the | as a delimiter to seperate the color-size
and quantity. Would my delimiter potentially screw up the unserialize
or serialize functions?
For multiple products here is a sample session.
cart|a:2:{s:9:"117-00717";s:20:"Black-Small_Medium|1";s:9:"117-00875";s:15:"Yellow-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
[2002-11-17 12:36:34] [EMAIL PROTECTED]
Missed a couple of words in the above. "will randomly be deleted" I
meant to write.
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/20449
--
Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Opn]: sessions randomly fail
ID: 20449
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
Ok. I think I have a really good idea as to what the bug is.
I am pretty sure there is a bug in the session serialization functions.
(and perhaps the normal php serialize/unserialize function)
It appears that the serialization does not handle arrays 100%
correctly. It works some of the times, but sometimes, the arrays get
completely lost. (thus the reason why the cart variable suddenly
changes to null)
Over the last couple of days, I implemented my own session code. I
stopped using $_SESSION and used my own method. (exact same concept
though)
I now use $GLOBALS["MYSESSION"] and I use serialize and unserialize
along with a session start and session save function. I store to the
exact same mysql session table that I did with code before.
We noticed an immediate improvement in sales of about 10-20 per day.
We were struggling to get to the 70-80 mark. The day I implemented the
new session code, we received 95 orders, the next day we received 91.
Today we are over 100!
I do however, still notice some null carts though. I think the normal
php serialize/unserialize function has a problem as well. However, it
is obviously more stable than whatever the $_SESSION code uses. (I
would assume the session code uses the regular php serialize functions?
if so, then calling serialize directly and not letting php handle the
sessions at all is more reliable)
So today I have written some further code to preconvert arrays into
strings. Thus, I will only be passing a normal string to
serialize/unserialize since it seems to handle strings perfectly. My
session start and save functions do all the conversion of string->array
and vice versa. I'll drop a note in here tomorrow to report how that
goes.
As a side note: as a programmer, I realize that thinking there is a bug
in those functionns is one thing. I know that since I can't provide
code that breaks it, it will be damn hard to debug. My only thought is
that it works most of the time so why wouldn't it work every time. I
too would probably tell myself that I'm smoking crack and the bug must
be elsewhere. But, I've been debugging everything else for over a
month. My recent changes brought a dramatic increase in orders so I
have to conclude that the bug lies somewhere in the php session code.
Again, I'll let you know how serializing only a string goes and not
letting serialize get a hold of an array.
Previous Comments:
[2002-11-21 15:29:24] [EMAIL PROTECTED]
NULL
[2002-11-21 09:54:16] [EMAIL PROTECTED]
I just noticed something in my session table.
a:2:{s:4:"cart";N;s:10:"gobackpage";N;}
What does N mean?
[2002-11-17 22:56:14] [EMAIL PROTECTED]
Changing my delimiter has not helped either.
This is really hard to reproduce. But it is happening. I don't know
if adding a second server to share the load will help or not. While we
will be adding a second server tomorrow, we really shouldn't have to.
What should I do next?
Josh
[2002-11-17 17:32:18] [EMAIL PROTECTED]
I set the gc_probability to 0. After 5 hours, I got another dozen
notifications that the cart failed. I even got a tech support
complaint from a customer.
My hunch is that the serializer is obliterating the array. One of the
recent things I started to do was to initialize $_SESSION["cart"] =
Array(); when they first enter the site. On the sessions that have
problems, the cart variable disappears. However, other session
variables still exist.
No where on the site do I attempt to destroy the session.
I'm going to change my | delimiter as I notice that the serializer uses
a | as a delimiter. I wonder if that could be it. (though, it works
most of the time)
I've made the other changes to the handler. I still see problems
though. Is there any particular user behaviour that could explain it?
I had someone suggest to me that a user double clicking the add to cart
button could do it. I don't see how though. Not only that, I've tried
clicking more than once myself and have never seen the problem.
Josh
[2002-11-17 12:42:17] [EMAIL PROTECTED]
Ok. I will fix my handler using your suggestions. I'll get back to
you after a few hours of letting it work.
Josh
--
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: After a good weekend we are having an incredible Monday. My code in place now uses serialize/unserialize. I also convert my arrays to strings with implode/explode before the serialization/unserialization process. I don't see any missing information anymore in my session table. I really think the session serialize code is at fault for this bug. Specifically I think it simply doesn't handle arrays. (perhaps objects but my object simply had the array in it. Removing the array from the object and not using objects did not work) This is an extremely serious bug that was costing us on average of about 30-50 orders a day. I am honestly not exaggerating on this figure. I tried the CVS version as late as 11-15-2002 and it still had the bug in it. Before that I was using the latest 4.2.3 version. I'd like a little feedback from the developers to at least say they are looking into it. I will try to assist in any way I can. However, as I have said before, it was very random and I myself never saw my session disappear. Also important to note is that I do not rely on Session Cookies so it is not related to cookies. Also, I tried doing the reset(arrayvar) after each session restoration as suggested on one of the session man pages. That too did not work. I hesitate to say but I really think it would be important to make note to people that the session code is not reliable. Perhaps in the man pages. I won't go to such length though as to warn them myself though I feel some duty to do so. Perhaps the bug only comes into play on high traffic servers. Either which way, not relying on the internal session code has made a huge difference. That in itself should prove something. Previous Comments: [2002-11-25 11:46:34] [EMAIL PROTECTED] This seems to be exactly the same problem we are having with one particular visitor to one of my websites. He always has this problem, every time he logs in his session expires. I have gone through his client PC configuration very carefully, and cannot find anything unusual. What's more odd is that he used to be able to use my site without problems. Would this problem manifest itself at random, or would it affect specific PCs? I had assumed the problem was at his end until I read this message thread, and it looked strangely familiar. Jolyon [2002-11-22 16:20:08] [EMAIL PROTECTED] Just thought I'd add that we are having what - seems to be - the same problem. We are running on Solaris 8 and our sessions are being held in a tmpfs mount that's balanced across 4 sun 220's. PHP Version 4.2.2 and Apache 1.3.26 compiled staticly. We've been moving the session store method around thinking I/O was the issue but it hasn't helped. We've done NFS mounted share, local-only share on 1 220 (limiting the load-balancing for one site to only that box) and now tmpfs. Our sessions are rather large (at least for me) normally around 11,316 bytes with objects and arrays w/ members that are serialized objects. It's probably important to note that we are avoiding automatic serialize/deserialize of objects by doing $_SESSION['someName'] = serialize($Object) type stuff. In almost all cases the sessions are there, but a couple values are simply missing. If you need anyother info please let me know. [2002-11-21 21:52:36] [EMAIL PROTECTED] Ok. I think I have a really good idea as to what the bug is. I am pretty sure there is a bug in the session serialization functions. (and perhaps the normal php serialize/unserialize function) It appears that the serialization does not handle arrays 100% correctly. It works some of the times, but sometimes, the arrays get completely lost. (thus the reason why the cart variable suddenly changes to null) Over the last couple of days, I implemented my own session code. I stopped using $_SESSION and used my own method. (exact same concept though) I now use $GLOBALS["MYSESSION"] and I use serialize and unserialize along with a session start and session save function. I store to the exact same mysql session table that I did with code before. We noticed an immediate improvement in sales of about 10-20 per day. We were struggling to get to the 70-80 mark. The day I implemented the new session code, we received 95 orders, the next day we received 91. Today we are over 100! I do however, still notice some null carts though. I think the normal php serialize/unserialize function has a problem as well. However, it is obviously more stable than whatever the $_SESSION
#19783 [Com]: A big problem with fread() with PHP4.3.0
ID: 19783
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Filesystem function related
Operating System: WindowsNT/XP/2000/9x
PHP Version: 4CVS-2002-10-06
New Comment:
I got a similar problem with :
apache 1.3.27
PHP 4.2.3
Os : Win NT 4
I do :
$fp = @fopen($localfile, "rb");
while (!feof($fp)) {
fwrite($file2,fread($file1, filesize($localfile)));
}
The size are differents on some test file (not all)
When the probleme occured the dest file is all the time smaller than
the source file ...
}
fclose($fp);
Previous Comments:
[2002-10-13 09:09:20] [EMAIL PROTECTED]
Sorry, my previous submitted problem is not related to this bug.
Please see Bug #19886.
[2002-10-13 08:52:31] [EMAIL PROTECTED]
Reopened this bug.
readfile() on 4.0, 4.2.4-dev and latest CVS-snapshot (13-Oct-2002
03:27) won't work with large files in Windows.
Even
$ptfp=fopen($ipoc_passthru_fn,"rb");
while(!feof($ptfp))
{
print fread($ptfp,4096);
}
fclose($ptfp);
won't work.
Files <100k work fine, larger don't.
This error is reproductive on various computers with different
Windows-Systems and occurs while trying to pass through PDF-files.
[2002-10-06 20:56:44] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-10-06 20:28:21] [EMAIL PROTECTED]
This bug looks really important.
I dont know if it is because of the new handling of streams but I just
verified that its working with PHP4.2.3 and not wit h 4_3 latest.
[2002-10-06 14:14:32] [EMAIL PROTECTED]
on some of my code I use the following:
$fd=fopen($filename,"rb");
echo fread($fd,filesize($filename));
fclose($fd);
It looks fread is limited to a certain value. I can't get more than a
certain size. With bigs files, I dont get all of them but just a part
so I had to use fgets.
Can someone check if something changed on the fread()'s function that
would limit it?
--
Edit this bug report at http://bugs.php.net/?id=19783&edit=1
#18363 [Com]: [chm] bug on function.fread.html
ID: 18363
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Reproducible crash
Operating System: windows
PHP Version: 4.2.1
New Comment:
I got a similar problem with file which containt 1A (hexa) but no crash
the fread only skip the 1A ... on Win NT with Apache/1.3.27 (Win32)
PHP/4.2.3
I have the same probleme with : Apache/1.3.27 (Win32) PHP/4.4.0-dev
for example a 7437824 bytes files become a 7.437.722 Bytes files
here is the code I use :
$file1 = @fopen($localfile, "rb");
$file2 = @fopen($destfile, "w");
while (!feof($fp)) {
fwrite($file2,fread($file1, filesize($localfile)));
}
Previous Comments:
[2002-10-17 01:00:01] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2002-10-01 18:09:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I've tried opening various exe and com files and I am unable to
replicate the crash you've reported. Please try the latest release and
see if the problem still occurs.
[2002-07-23 00:59:02] [EMAIL PROTECTED]
When reading with the function fread I have found an error when read
hexadecimal "1A", not, but I believe that they must more of the sort
have.
[2002-07-17 02:52:42] [EMAIL PROTECTED]
for example:(abc.exe is execution file)
$fp=fopen("abc.exe","rb");
$exe_get=fread($fp,filesize("abc.exe"));
[2002-07-17 02:18:43] [EMAIL PROTECTED]
oops...misunderstood (!) this.
Can you please show us a SHORT example script which
causes this crash?
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/18363
--
Edit this bug report at http://bugs.php.net/?id=18363&edit=1
Bug #14594 Updated: Failed to compile/run when using Apache 2.x, unresolved symbols
ID: 14594 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: FreeBSD 4.4-STABLE PHP Version: 4.1.0 New Comment: Same results on FreeBSD 4.2-RELEASE with Apache 2.0.35 / PHP 4.2.0RC4 Previous Comments: [2002-04-15 08:15:12] [EMAIL PROTECTED] Exactly the same error here. FreeBSD 4.5 / Release Apache 2.0.35 PHP 4.2.0RC4 Tried: ./configure --with-apache=/usr/local/apache2/bin/apxs --with-tsrm-pth Didn't work: ./apachectl configtest Syntax error on line 217 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp4.so into server: /usr/local/apache2/modules/libphp4.so: Undefined symbol "pthread_getspecific" [2002-04-14 19:30:10] [EMAIL PROTECTED] i had the same problem. using freebsd 4.5, apache 2.0.25, php 4.2.0RC3 trying with gnu-pth [2002-04-07 11:42:12] [EMAIL PROTECTED] Same problem still on FreeBSD4.5 tested with: apache cvs 2.0.36 with php4.2.0RC2 apache cvs 2.0.36 with last php cvs (update on 7/04) apache release 2.0.35 with php4.2.0RC apache release 2.0.35 with last php cvs finally works with using trsm-pth with in php configure. [2002-04-06 15:04:18] [EMAIL PROTECTED] FreeBSD 4.5-RELEASE Apache 2.0.35 CVS PHP (pulled 2002-04-06 ~14:00 EST) PHP config line: ./configure --with-apxs2 --enable-track-vars --enable-versioning --with-mysql=/usr/local/mysql And the result: Cannot load /usr/local/lib/apache/modules/libphp4.so into server: /usr/local/lib/apache/modules/libphp4.so: Undefined symbol "pthread_getspecific" [2002-04-06 11:08:11] [EMAIL PROTECTED] Does this happen with latest CVS versions of PHP and Apache2? 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/14594 -- Edit this bug report at http://bugs.php.net/?id=14594&edit=1
Bug #16777 Updated: Multiple odbc connections failing
ID: 16777
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ODBC related
Operating System: win 2000
PHP Version: 4.2.0
New Comment:
I am having this problem as well. The cursor seems to be using the
default "forward-only" mode. I assume PHP 4.1 automatically generated
a static cursor and 4.2 is not?
Any ideas? This totally screws up the web application I'm working on.
Previous Comments:
[2002-05-01 08:41:06] [EMAIL PROTECTED]
I believe this is fixed in CVS. Please try one of the latest CVS
snapshots, and see if it solves the problem for you. If not, reopen
the bug...
[2002-04-30 10:56:23] [EMAIL PROTECTED]
OK, simple version:
$var = odbc_exec($cnx,Some query);
$row = 0;
while (odbc_fetch_row($var)){
$row++;
$res1 = odbc_fetch_row($var, 1 );
$res2 = odbc_fetch_row($var, 2 );
$var2 = odbc_exec($cnx,Select * from some table
where field = $res1);
while (odbc_fetch_row($var2)){
$row++;
$res3 = odbc_fetch_row($var2, 1 );
$res4 = odbc_fetch_row($var2, 2 );
}
}
[2002-04-30 03:59:05] [EMAIL PROTECTED]
a simplified example would be :
$res=odbc_exec($conn,"select * from categorii order by
ordine_categorie");
for($i=1;odbc_fetch_row($res);$i++)
{
$res2=odbc_exec($conn,"select * from subcategorii where
id_categorie=$idcateg order by ordine_subcategorie");
..
}
the second query fails but ONLY when the first return more than one
row. i tried with different connections but doesn't work.
check my original post at
http://news.php.net/article.php?group=php.db&article=18880
[2002-04-24 18:48:52] [EMAIL PROTECTED]
Can you please provide a simplified test case that doesn't work for
you?
[2002-04-23 19:52:33] [EMAIL PROTECTED]
I would like to apologize, for I have uninstalled 4.2 from my server
and went back to 4.1, and now I do not have the complete error
messages.
Server: Windows 2000 IIS
SQL server 2k
PHP ver 4.2
odbc
Problem: Old scripts that ran fine on version 4.1.2 now give error
messages stating that the odbc connection is in use "SQLstate S1000
waiting for result from previous hstmnt"
We have scoured the INI, tried the old ini as well. same results. I put
4.1.2 back on, issue is gone.
I am running into this issue when looping through the Db and running a
subloop inside based off results from the first loop. I do this with
functions inside a loop as well as actually running a new while loop
inside of the first one. I have tried altering my code, making sure i
have closed all db connections (which i never do) and free allodbc
results from memory.
sample codes:
here are the defined functions:
function countapproved ($project_id){
$time = date ("H:i");
$date = date("m/d/y");
$cto_f = odbc_connect("emp1","","")
or die("Error Connecting To CDBMS.");
$cnt_rec = ("select count (*) from [cto_main] where emp_pro
='$project_id' and date = '$date' and pref_time < '$time' and
cto_status_id <> '2' and cto_status_id <> '3' and (shift_time >
'$time')");
$ex_cr = odbc_exec($cto_f,$cnt_rec);
$count = odbc_result($ex_cr, 1);
return $count;
}
function countgranted ($project_id){
$time = date ("H:i");
$date = date("m/d/y");
$cto_f = odbc_connect("emp1","","")
or die("Error Connecting To CDBMS.");
$cnt_rec = ("select count (*) from [cto_main] where emp_pro
='$project_id' and date = '$date' and cto_status_id = '2'");
$ex_cr = odbc_exec($cto_f,$cnt_rec);
$count = odbc_result($ex_cr, 1);
return $count;
}
function countsignedout ($project_id){
$time = date ("H:i");
$date = date("m/d/y");
$cto_f = odbc_connect("emp1","","")
or die("Error Connecting To CDBMS.");
$cnt_rec = ("select count (*) from [cto_main] where (emp_pro
='$project_id') and (date = '$date') and cto_status_id = '3'");
$ex_cr = odbc_exec($cto_f,$cnt_rec);
$count = odbc_result($ex_cr, 1);
return $count;
}
function countpending ($project_id){
$time = date ("H:i");
$date = date("m/d/y");
$cto_f = odbc_connect("emp1","","")
or die("Error Connecting To CDBMS.");
$cnt_rec = ("select count (*) from [cto_main] where emp_pro
='$project_id' and date = '$date' and pref_time > '$time' and
cto_status_id <> '2' and cto_status_id <> '3' and (shift_time >
'$time')");
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: HTTP related Operating System: Tru64 PHP Version: 4.2.2 New Comment: Hi, I get the same problem with Linux RH8.0 using the default RPMs (which includes apache part deux). As a workaround I am adding: into my one field forms. thanks, josh. Previous Comments: [2002-09-11 11:49:02] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-08-15 23:09:06] [EMAIL PROTECTED] Tested this with latest snapshot and Apache 1.3.26 on Tru64, seems to work fine. So Jani might be right with his Apache2-Guess. [2002-08-15 07:15:47] [EMAIL PROTECTED] Common for both cases seems to be Apache2..please try with Apache 1.3.26 (and the latest snapshot from today, url above). Apache2 support is experimental btw. [2002-08-15 06:08:55] [EMAIL PROTECTED] HelloAll, I can confirm this issue. I have the same problem on solaris, linux platforms. I've downloaded snapshot from 15082002, but it is the same on my Linux RH7.3 platform. Here are my configure options ./configure' '--with-apxs2=/internet/www/httpd-2.0.39/bin/apxs' '--with-config-file-path=/internet/www/' '--disable-debug' '--enable-sigchild' '--with-gdbm' '--with-zlib' '--enable-track-vars' '--enable-magic-quotes' '--with-dbase' '--with-gd' '--with-ttf' '--with-mysql=/opt/mysql/mysql' '--enable-ftp' '--with-gettext' '--with-iconv=/usr/local' '--enable-trans-sid' '--with-pdflib' '--enable-xml' '--enable-xslt' '--with-xslt-sablot' '--with-dom' '--with-pgsql=/opt/pgsql' '--enable-wddx' '--with-pear=/internet/www/php/' '--enable-mailparse' '--with-xmlrpc' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' [2002-08-02 13:25:26] [EMAIL PROTECTED] Sorry about the delay... That snapshot (php4-200207310300) made no difference :-( Tried with both Compaq cc and gcc 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/18648 -- Edit this bug report at http://bugs.php.net/?id=18648&edit=1
Bug #15979: When adding 0.01 in a loop, math starts getting incorrect
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.2 PHP version: 4.1.2 PHP Bug Type: Math related Bug description: When adding 0.01 in a loop, math starts getting incorrect http://freedns.afraid.org/tools/test.phps http://freedns.afraid.org/tools/test.php Here's the output of where the problem starts happening: 4.39 4.4 4.41 4.42 4.42999 4.43999 4.44999 4.45999 I get 4.42999 instead of 4.43 Josh -- Edit bug report at http://bugs.php.net/?id=15979&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15979&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15979&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15979&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15979&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15979&r=support Expected behavior: http://bugs.php.net/fix.php?id=15979&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15979&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15979&r=submittedtwice
#6333 [Com]: garbage collection is not being performed on create_function?
ID: 6333
Comment by: josh at mykoala dot com
Reported By: ewdafa at ewdafa dot b0rk dot co dot uk
Status: Closed
Bug Type: Performance problem
Operating System: linux-2.2.16
PHP Version: 4.0.1pl2
New Comment:
It's been said that this is just how the function works,
but it seems as though destroying allocations for an
anonymous function when redefining to the same variable
would be the way to handle it. Example:
for ($i=0; $i<10; $i++) {
$echoit = create_function('$wha', 'echo $wha;');
echo memory_get_usage();
$echoit(" on iteration: #$i\n");
}
How else can you dynamically modify function or code
without reloading a script?
Previous Comments:
[2000-09-07 11:43:23] [EMAIL PROTECTED]
This isn't a bug but how it works. Each create_function() call creates
a new unique function. So obviously if you define zillions in an
infinite loop you'll run out of memory.
[2000-08-24 09:57:38] ewdafa at ewdafa dot b0rk dot co dot uk
the following code causes PHP to continually eat more and more memory
where it should be destroying the old reference for $func.
while(1) {
$array = array();
$func = create_function('', "return 0;");
$array[] = $func;
$func = 0;
echo "sleeping for a second.\n";
sleep(1);
}
--
Edit this bug report at http://bugs.php.net/?id=6333&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: josh at bauguss dot net Reported By: josh at zebotech dot com Status: No Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: I just got the last comment sent to me in my email so I rechecked this bug. I'm suprised to see that most of the comments that I had posted to this bug are now gone. I'm also really suprised that this bug report had been suspended. Just for the last guys benefit for his comment on this bug... I wrote my own session handling routine and that completely fixed the problem. I now don't use any of the session calls built into php. I also wrote my own serialize/deserialize function. While I can't prove it at the moment as I don't have time to, I'm pretty sure that the problem with the session handler is with the serialize/deserialize routine used by the session handler. I seem to remember this being my conclusion way back over a year ago and I think I even provided comments in this bug report that seem to no longer be attached to this bug. I can't recall at the moment nor can I risk testing it on my site, but I think when I tried using the serialize/deserialize function in php in my own session manager I ran into the same symptoms of this bug. When I wrote my own routine, it disappeared and solved my session management woes. Hope that helps. Josh Bauguss Previous Comments: [2004-01-16 15:30:26] dspice at samys dot com I was extremely relieved to find this post, as I've been having the identical problem. However, it seems like it's not yet resolved in any practical manner. The same scenario occurs for me: a small but important number of users lose the data in the session arrays (but not the session itself) - I believe when the protocol switches from http to https. I have tried many times on many machines to replicate it; so far of the customers I have been able to get data from, it seems they are all running IE6 on Windows XP, but that could easily just be statistical probability. I've tried to replicate the problem using the exact same IE version number, with no success. I can't tell how many people this is affecting, exactly, but I can tell that it's costing us money. It's reassuring to see other people facing the same problem, but disparaging to see that it's been over a year and this apparent bug still has not been resolved. Any help would be greatly appreciated. [2003-06-09 08:44:10] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-06-02 17:09:32] [EMAIL PROTECTED] This should be fixed in PHP 4.3.2, so please give it a try. [2003-05-09 00:18:19] php dot bugs dot krishaven at spamgourmet dot com My session problems appear to all be caused by the fact that $array1=$array2 doesn't do a "deep copy" as described in bugs: http://bugs.php.net/bug.php?id=8130 http://bugs.php.net/bug.php?id=21288 http://bugs.php.net/bug.php?id=20993 Personally, I don't think that the previous dismissal of the problem with "This will not be fixed anytime soon. It is a deep seated problem in the implementation and fixing it would cause speed problems and numerous other problems," or considering it a documentation problem are appropriate responses. I guess I was lucky that this was causing an apache segfault, or who knows how much data this could have corrupted? [2002-11-21 15:29:24] russ at zerotech dot net NULL 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#27152 [NEW]: fam_next_event() doesn't return the corresponding request
From: josh at mediascape dot com Operating system: Linux PHP version: 5.0.0b3 (beta3) PHP Bug Type: Feature/Change Request Bug description: fam_next_event() doesn't return the corresponding request Description: The array returned by fam_next_event() contains "filename", "code" and possibly "hostname", but it doesn't return any indicator of the FAMRequest that the event belongs to. The underlying library returns this as the "fr" member of the FAMEvent struct -- "FAMRequest *fr;". When monitoring multiple directories, this additional context is needed, since the filenames returned have no associated path information. Reproduce code: --- -- Sample PHP FAM client -- #! /usr/local/bin/php5 -- Sample filesystem activity to trigger it -- $ touch /tmp/blib $ touch /var/tmp/blib Expected result: I would expect fam_next_event() to return either the resource handle for the underlying FAMRequest structure (also returned by fam_monitor_directory() -- $r1 and $r2 in the code above), or the path argument to the fam_monitor_*() function so that the client code can reconstruct something meaningful from the returned event. As an example, here's the modified lines inside the while() loop above, but expecting that fam_next_event() also returns the resource handle corresponding to fe->fr in the underlying struct: print "File: $event[filename]\n"; print "Code: $event[code]\n"; print "Request: $event[request]\n"; $req = intval($event['request']); print "Path: ".($req == intval($r1) ? '/tmp' : '/var/tmp') . "\n\n"; I hesitate to produce the patch to php-5.0b3 I used to test this, only because I've never looked under PHP's hood before, and someone that knows what they're doing would likely produce the same changes at least as quickly as finding the SIGSEGV that I created in the process. Actual result: -- [Skipping the list of files that already exist for brevity] File: blib Code: 5 File: blib Code: 5 -- Compared with the result from my test build -- File: blib Code: 5 Request: Resource id #5 Path: /tmp File: blib Code: 5 Request: Resource id #6 Path: /var/tmp -- Edit bug report at http://bugs.php.net/?id=27152&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27152&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27152&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27152&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27152&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27152&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27152&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27152&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27152&r=support Expected behavior: http://bugs.php.net/fix.php?id=27152&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27152&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27152&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27152&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27152&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27152&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27152&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27152&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27152&r=float
#26045 [Com]: Mono extension fails to compile
ID: 26045
Comment by: josh at mediascape dot com
Reported By: kris dot hofmans at pandora dot be
Status: Assigned
Bug Type: Compile Failure
Operating System: Linux 2.4.21
PHP Version: 5CVS-2003-10-30 (dev)
Assigned To: sterling
New Comment:
Here's a minimal patch to make the extension build again:
http://w3.indecisive.com/patches/php-5.0b3-mono.patch
This sample still doesn't run correctly with the patch applied:
php -r "$cons = new Mono('System.Console');"
On the other hand, the System.Collections.Stack sample that just checks
for proper pushing and popping worked for me.
Previous Comments:
[2003-10-30 21:02:47] [EMAIL PROTECTED]
Assigned to the author of this extension.
[2003-10-30 19:11:06] kris dot hofmans at pandora dot be
Description:
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c: In function
`method_get':
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:667: structure has
no member
named `arg_types'
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c: At top level:
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:740: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:742: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:745: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:746: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:748: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:749: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:750: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:751: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:753: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:755: warning:
initialization
from incompatible pointer type
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c: In function
`zm_startup_mon
o':
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:1041: structure has
no membe
r named `arg_types'
/home/blacky/builds/php-5.0.0b2/ext/mono/php_mono.c:1054: structure has
no membe
r named `arg_types'
make: *** [ext/mono/php_mono.lo] Error 1
make: *** Waiting for unfinished jobs
Expected result:
I hope the mono extension will be fixed since the last working version
I saw was PHP5-B1 and it got broken soon after that.
--
Edit this bug report at http://bugs.php.net/?id=26045&edit=1
#27380 [NEW]: Segmentation fault executing do..while() loops inside block containers
From: josh at hostyour dot info
Operating system: RH7.3
PHP version: 4.3.4
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault executing do..while() loops inside block
containers
Description:
If I have a function that has a do..while(); construction in it, inside a
block container { }, PHP will segfault on exiting the block container
UNLESS I have a statement in between the end of the while (); and the
closing brace of the block.
This does NOT happen in "global" execution. A do..while() loop that lives
outside any function's scope works just fine; I have several other
do..while() constructs outside of functions that work with no problems.
The segfault seems to only happen when the do..while(); is inside a
function AND inside a block container (in this case, belonging to an if
statement).
Any ideas?
Reproduce code:
---
function announce()
{
global $totalRows_announce, $row_announce, $announce, $srs;
$ann = "";
if ($totalRows_announce > 0) {
do {
$author = mysql_result(mysql_query("SELECT nick FROM players
WHERE
id='".$row_announce['author']."'", $srs), 0, "nick") or
die(mysql_error());
$msg_body =
stripslashes(implode("",explode("\n",$row_announce['msg_body'])));
$ann .= textBlock(textBlock($row_announce['subject'], "",
"anntitle") .
br() .
textBlock("Posted by:".$author." | On:
".$row_announce['posted_date'],
"", "annhead") . br() .
textBlock($msg_body, "", "annbody"), "",
(($row_announce['urgent'] ==
1) ? "redrow" : ((($ctr++) % 2) ? "lightrow" : "darkrow"))) . br();
} while ($row_announce = mysql_fetch_assoc($announce));
// Segfault happens HERE
} else {
$ann = textBlock("No Announcements", "", "loginerr");
}
return $ann;
}
Expected result:
The code, as intended, returns a string of HTML code to the calling
function.
Actual result:
--
The code immediately segfaults when it encounters the closing brace of the
do..while() loop's block container UNLESS there is an intervening
statement.
--
Edit bug report at http://bugs.php.net/?id=27380&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27380&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27380&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27380&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27380&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27380&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27380&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27380&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27380&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27380&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27380&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27380&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27380&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27380&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27380&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27380&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27380&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27380&r=float
#22656 [NEW]: socket_set_blocking() won't work?
From: thejoshes at josh dot com Operating system: OS X 10.2.3 PHP version: 4.3.1 PHP Bug Type: Sockets related Bug description: socket_set_blocking() won't work? The following script produces this error: Warning: socket_set_blocking(): supplied resource is not a valid stream resource in /Users/josha/test/noblock.php on line 10 Even though the socket connection will work fine... I expect this to work, since $s is indeed a valid stream resource, right? #!/usr/local/bin/php -- Edit bug report at http://bugs.php.net/?id=22656&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22656&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22656&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22656&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22656&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22656&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22656&r=support Expected behavior: http://bugs.php.net/fix.php?id=22656&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22656&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22656&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22656&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22656&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22656&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22656&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22656&r=gnused
#22656 [Bgs->Opn]: socket_set_blocking() won't work?
ID: 22656 User updated by: thejoshes at josh dot com Reported By: thejoshes at josh dot com -Status: Bogus +Status: Open Bug Type: Sockets related Operating System: OS X 10.2.3 PHP Version: 4.3.1 New Comment: Interesting. When I use socket_set_nonblock($s); instead, I get the following error, repeatedly: Warning: socket_accept() unable to accept incoming connection [35]: Resource temporarily unavailable in /Users/josha/test/noblock.php on line 27 Previous Comments: [2003-03-12 03:29:39] [EMAIL PROTECTED] I was going to suggest reading the manual, however this point is not made clear: socket_set_blocking() has nothing to do with the sockets extension, and that is the reason that we changed its name: http://www.php.net/manual/en/function.socket-set-blocking.php http://www.php.net/manual/en/function.stream-set-blocking.php To acheive non-blocking "ext/sockets", you need to call this function: http://www.php.net/manual/en/function.socket-set-nonblock.php [2003-03-12 02:32:21] thejoshes at josh dot com The following script produces this error: Warning: socket_set_blocking(): supplied resource is not a valid stream resource in /Users/josha/test/noblock.php on line 10 Even though the socket connection will work fine... I expect this to work, since $s is indeed a valid stream resource, right? #!/usr/local/bin/php -- Edit this bug report at http://bugs.php.net/?id=22656&edit=1
#22887 [NEW]: sprintf( "%.2f", 10.75 ); returns "0.00"
From: josh at chatgris dot com Operating system: Gentoo Linux /w apache2 PHP version: 4.3.1 PHP Bug Type: Scripting Engine problem Bug description: sprintf( "%.2f", 10.75 ); returns "0.00" Sample script returns 0.00 this is NOT the expected behaviour. Using apache2, not tested on apache1. -- Edit bug report at http://bugs.php.net/?id=22887&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22887&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22887&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22887&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22887&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22887&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22887&r=support Expected behavior: http://bugs.php.net/fix.php?id=22887&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22887&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22887&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22887&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22887&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22887&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22887&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22887&r=gnused
#22887 [Fbk->Opn]: sprintf( "%.2f", 10.75 ); returns "0.00"
ID: 22887 User updated by: josh at chatgris dot com Reported By: josh at chatgris dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux /w apache2 PHP Version: 4.3.1 New Comment: I built it with the lastest snapshot (phpinfo said it was 4.3.2-RC) and the exact same problem is occuring. I have also made a sample C program to test the output of printf and it works in the C program. So it's definately something to do with php. Anything else I can do to help you guys figure this out? Josh. Previous Comments: [2003-03-26 09:25:30] [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 Cannot verify using Apache 2 either, if latest snapshot still has this problem, please include your configure line for PHP in your reply. [2003-03-26 00:28:12] [EMAIL PROTECTED] Works just fine from in CLI and Apache1. Don't have an Apache2 server handy for testing this. [2003-03-25 23:36:21] josh at chatgris dot com Sample script returns 0.00 this is NOT the expected behaviour. Using apache2, not tested on apache1. -- Edit this bug report at http://bugs.php.net/?id=22887&edit=1
#22887 [Opn]: sprintf( "%.2f", 10.75 ); returns "0.00"
ID: 22887
User updated by: josh at chatgris dot com
Reported By: josh at chatgris dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux /w apache2
PHP Version: 4.3.1
New Comment:
I am not the only one experiencing this problem.. plus it
seems to round the number randomly for example
echo sprintf('%.2f', '8.7586206896551724');
returns 10.00
the person who had this problem's post is here
http://forums.gentoo.org/viewtopic.php?t=38470&highlight=sprintf
Previous Comments:
[2003-03-27 21:55:28] [EMAIL PROTECTED]
It cannot be a general php problem as nobody here can reproduce it. It
has to something related to either Apache2 or some other factor unique
to your machine.
----
[2003-03-27 21:44:51] josh at chatgris dot com
I built it with the lastest snapshot (phpinfo said it was
4.3.2-RC) and the exact same problem is occuring.
I have also made a sample C program to test the output of
printf and it works in the C program. So it's definately
something to do with php.
Anything else I can do to help you guys figure this out?
Josh.
[2003-03-26 09:25:30] [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
Cannot verify using Apache 2 either, if latest snapshot still has this
problem, please include your configure line for PHP in your reply.
[2003-03-26 00:28:12] [EMAIL PROTECTED]
Works just fine from in CLI and Apache1. Don't have an
Apache2 server handy for testing this.
----
[2003-03-25 23:36:21] josh at chatgris dot com
Sample script
returns 0.00
this is NOT the expected behaviour.
Using apache2, not tested on apache1.
--
Edit this bug report at http://bugs.php.net/?id=22887&edit=1
#22887 [Opn]: sprintf( "%.2f", 10.75 ); returns "0.00"
ID: 22887
User updated by: josh at chatgris dot com
Reported By: josh at chatgris dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux /w apache2
PHP Version: 4.3.1
New Comment:
I believe the problem is related.. For example, we are
both using Pentium$ CPU's..
sprintf works fine on my Athlon, but not my pentium4...
In addition, his example produced the same output on my
machine. and I've tried putting the float in a variable,
float as a string it alwasy returns the same so I am
pretty sure that the problem is within sprintf..
Could anyone tell me where the sprintf code is in php? I
don't mind messing with it and trying to figure out what
is wrong...
Josh.
Previous Comments:
[2003-03-28 04:41:25] [EMAIL PROTECTED]
Works fine here (Gentoo with glibc 2.3.2), using php5 cvs from two days
ago (cli).
-tal
[2003-03-28 02:43:18] [EMAIL PROTECTED]
Just tried PHP4.3.2/5 with CLI/Apache1 on mdk/winxp. All
work fine and the code that might cause the problems is not sapi
dependant.
The external message you pointed to is different because he used a
string to be printed with %f. That means it must first be converted to
a number and then printed.
[2003-03-28 00:08:36] josh at chatgris dot com
I am not the only one experiencing this problem.. plus it
seems to round the number randomly for example
echo sprintf('%.2f', '8.7586206896551724');
returns 10.00
the person who had this problem's post is here
http://forums.gentoo.org/viewtopic.php?t=38470&highlight=sprintf
[2003-03-27 21:55:28] [EMAIL PROTECTED]
It cannot be a general php problem as nobody here can reproduce it. It
has to something related to either Apache2 or some other factor unique
to your machine.
[2003-03-27 21:44:51] josh at chatgris dot com
I built it with the lastest snapshot (phpinfo said it was
4.3.2-RC) and the exact same problem is occuring.
I have also made a sample C program to test the output of
printf and it works in the C program. So it's definately
something to do with php.
Anything else I can do to help you guys figure this out?
Josh.
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/22887
--
Edit this bug report at http://bugs.php.net/?id=22887&edit=1
#22887 [Opn]: sprintf( "%.2f", 10.75 ); returns "0.00"
ID: 22887
User updated by: josh at chatgris dot com
Reported By: josh at chatgris dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux /w apache2
PHP Version: 4.3.1
New Comment:
Thank you for the suggestion!!
I am going to try and compile my entire gentoo system from
scratch using mcpu=i686 (I feel kinda iffy using
march=pentium3 on a pentium4).
I'll respond as soon as I have new information.
Thanks again!!!!
Josh.
Previous Comments:
[2003-03-28 11:16:00] [EMAIL PROTECTED]
This is most likely being caused by over-optimization when
compiling. I had a similar problem on my gentoo box, and
the problem was traced back to over-optimizing when
compiling glibc. (var_dump() was printing some weird
floats, and I believe this problem is similar, as both use
modf() at some point.)
Basically, tone down the optimizations a bit. If you
compile glibc with CFLAGS along the lines of
"-march=pentium4 -O3...", modf() starts dying. The
solution (for gentoo, at least) is to modify your USE flag
in make.conf to use -march=pentium3 if you're using
pentium4 and re-emerge glibc, then recompile PHP.
gcc has problems with march pentium4 spitting out bad
instructions, so you should stay away from it, even if
you're actually on a Pentium 4. Use march=pentium3 or
mcpu=i686 instead. There are threads on the gentoo forums
about this, and newer versions of portage mention it in
the make.conf comments.
If this is indeed the problem, it affects python, too,
fwiw.
J
----
[2003-03-28 10:27:01] josh at chatgris dot com
I believe the problem is related.. For example, we are
both using Pentium$ CPU's..
sprintf works fine on my Athlon, but not my pentium4...
In addition, his example produced the same output on my
machine. and I've tried putting the float in a variable,
float as a string it alwasy returns the same so I am
pretty sure that the problem is within sprintf..
Could anyone tell me where the sprintf code is in php? I
don't mind messing with it and trying to figure out what
is wrong...
Josh.
[2003-03-28 04:41:25] [EMAIL PROTECTED]
Works fine here (Gentoo with glibc 2.3.2), using php5 cvs from two days
ago (cli).
-tal
[2003-03-28 02:43:18] [EMAIL PROTECTED]
Just tried PHP4.3.2/5 with CLI/Apache1 on mdk/winxp. All
work fine and the code that might cause the problems is not sapi
dependant.
The external message you pointed to is different because he used a
string to be printed with %f. That means it must first be converted to
a number and then printed.
[2003-03-28 00:08:36] josh at chatgris dot com
I am not the only one experiencing this problem.. plus it
seems to round the number randomly for example
echo sprintf('%.2f', '8.7586206896551724');
returns 10.00
the person who had this problem's post is here
http://forums.gentoo.org/viewtopic.php?t=38470&highlight=sprintf
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/22887
--
Edit this bug report at http://bugs.php.net/?id=22887&edit=1
#27528 [NEW]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
From: josh at netbits dot us Operating system: Linux SuSE 8.1 PHP version: 5.0.0b4 (beta4) PHP Bug Type: Apache2 related Bug description: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang Description: I compiled php 5.0.0b4 on a SuSE linux system. uname -a: Linux langly 2.4.19-4GB #1 Mon Aug 4 23:38:42 UTC 2003 i686 unknown gcc -v: Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.2 The configure command used the following options: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs \ \ --enable-exif \ --enable-ftp \ --enable-sockets \ --with-mcrypt \ --with-mhash \ --with-openssl \ --with-iconv \ --with-ncurses \ --with-readline \ --with-curl \ \ --with-bz2 \ --with-zip \ --with-zlib \ \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/usr/local/mysql/mysql.sock \ \ --with-pgsql=/usr/local/pgsql \ \ --with-oci8 \ \ --with-sqlite \ \ --with-gd \ --with-ttf \ --with-freetype \ --with-freetype-dir=/usr/X11/lib \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr \ \ --enable-xml \ --enable-wddx \ --with-xsl \ --with-expat-dir=/usr \ --with-libxml-dir=/usr/local \ --with-xmlrpc \ --with-dom \ --with-qtdom \ \ --with-java=/usr/local/java/ After installation and restarting apache (2.0.48), only one apache process is spawned - no additional threads are started. Attempts to access web pages with or without PhP hang until timing out - no messages are generated in the Apache error or access log. Single Apache process needs to be killed with kill -9. Re-instating PhP-4.3.4 module causes behavior to return to normal. ldd /usr/local/apache/modules/libphp5.so libcrypt.so.1 => /lib/libcrypt.so.1 (0x402a7000) libexslt.so.0 => /usr/local/lib/libexslt.so.0 (0x402d8000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402e7000) libhistory.so.4 => /lib/libhistory.so.4 (0x40307000) libreadline.so.4 => /lib/libreadline.so.4 (0x4030f000) libncurses.so.5 => /lib/libncurses.so.5 (0x4033b000) libpq.so.3 => /usr/local/pgsql-7.4.1/lib/libpq.so.3 (0x4037e000) libpanel.so.5 => /usr/lib/libpanel.so.5 (0x40398000) libmysqlclient.so.14 => /usr/local/mysql-5.0.0-alpha/lib/mysql/libmysqlclient.so.14 (0x4039c000) libmhash.so.2 => /usr/lib/libmhash.so.2 (0x40484000) libmcrypt.so.4 => /usr/local/lib/libmcrypt.so.4 (0x404a6000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x404db000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404e2000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40524000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4061c000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4062b000) libz.so.1 => /lib/libz.so.1 (0x4065b000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4066a000) libbz2.so.1 => /usr/lib/libbz2.so.1 (0x40688000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40698000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x406c8000) libresolv.so.2 => /lib/libresolv.so.2 (0x4079e000) libm.so.6 => /lib/libm.so.6 (0x407b) libdl.so.2 => /lib/libdl.so.2 (0x407d3000) libnsl.so.1 => /lib/libnsl.so.1 (0x407d6000) libcurl.so.2 => /usr/local/lib/libcurl.so.2 (0x407eb000) libclntsh.so.8.0 => /opt/oracle/product/8i/lib/libclntsh.so.8.0 (0x40815000) libxslt.so.1 => /usr/local/lib/libxslt.so.1 (0x40d89000) libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x40db9000) libc.so.6 => /lib/libc.so.6 (0x40ea9000) libpthread.so.0 => /lib/libpthread.so.0 (0x40fc7000) libwtc8.so => /opt/oracle/product/8i/lib/libwtc8.so (0x40fdc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) Other information: MySQL 5.0, curl-7.11.0, libmcrypt-2.5.7, libxml2-2.6.7, and libxslt-1.1.4 built from source. # java -version java version "1.4.2_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode) I will attempt to build from CVS. Josh Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit bug report at http://bugs
#27528 [Fbk->Opn]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
ID: 27528 User updated by: josh at netbits dot us Reported By: josh at netbits dot us -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux SuSE 8.1 PHP Version: 5.0.0b4 (beta4) New Comment: # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Using the php-5.0.0b4 release with these options works fine. Of course, it's not very useful. :) Also verified that httpd.conf did not contain additional load_module calls. I do not install any disto software for php/apache/mysql/etc and control all of this by building from source. Josh Previous Comments: [2004-03-09 08:43:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip And try this for PHP: # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Also, make sure you're NOT loading any other PHP versions the same time in your apache httpd.conf (some distros come with preinstalled PHP, so..) ---- [2004-03-08 15:51:25] josh at netbits dot us Description: I compiled php 5.0.0b4 on a SuSE linux system. uname -a: Linux langly 2.4.19-4GB #1 Mon Aug 4 23:38:42 UTC 2003 i686 unknown gcc -v: Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.2 The configure command used the following options: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs \ \ --enable-exif \ --enable-ftp \ --enable-sockets \ --with-mcrypt \ --with-mhash \ --with-openssl \ --with-iconv \ --with-ncurses \ --with-readline \ --with-curl \ \ --with-bz2 \ --with-zip \ --with-zlib \ \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/usr/local/mysql/mysql.sock \ \ --with-pgsql=/usr/local/pgsql \ \ --with-oci8 \ \ --with-sqlite \ \ --with-gd \ --with-ttf \ --with-freetype \ --with-freetype-dir=/usr/X11/lib \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr \ \ --enable-xml \ --enable-wddx \ --with-xsl \ --with-expat-dir=/usr \ --with-libxml-dir=/usr/local \ --with-xmlrpc \ --with-dom \ --with-qtdom \ \ --with-java=/usr/local/java/ After installation and restarting apache (2.0.48), only one apache process is spawned - no additional threads are started. Attempts to access web pages with or without PhP hang until timing out - no messages are generated in the Apache error or access log. Single Apache process needs to be killed with kill -9. Re-instating PhP-4.3.4 module causes behavior to return to normal. ldd /usr/local/apache/modules/libphp5.so libcrypt.so.1 => /lib/libcrypt.so.1 (0x402a7000) libexslt.so.0 => /usr/local/lib/libexslt.so.0 (0x402d8000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402e7000) libhistory.so.4 => /lib/libhistory.so.4 (0x40307000) libreadline.so.4 => /lib/libreadline.so.4 (0x4030f000) libncurses.so.5 => /lib/libncurses.so.5 (0x4033b000) libpq.so.3 => /usr/local/pgsql-7.4.1/lib/libpq.so.3 (0x4037e000) libpanel.so.5 => /usr/lib/libpanel.so.5 (0x40398000) libmysqlclient.so.14 => /usr/local/mysql-5.0.0-alpha/lib/mysql/libmysqlclient.so.14 (0x4039c000) libmhash.so.2 => /usr/lib/libmhash.so.2 (0x40484000) libmcrypt.so.4 => /usr/local/lib/libmcrypt.so.4 (0x404a6000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x404db000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404e2000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40524000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4061c000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4062b000) libz.so.1 => /lib/libz.so.1 (0x4065b000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4066a000) libbz2.so.1 => /usr/lib/libbz2.so.1 (0x40688000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40698000) libcrypto.so.0.9.6 => /usr/lib/l
#27528 [Opn]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
ID: 27528 User updated by: josh at netbits dot us Reported By: josh at netbits dot us Status: Open Bug Type: Apache2 related Operating System: Linux SuSE 8.1 PHP Version: 5.0.0b4 (beta4) New Comment: Forgot, I also tried my original configure commands with CVS snapshot from yesterday afternoon - same results. Previous Comments: [2004-03-09 11:58:15] josh at netbits dot us # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Using the php-5.0.0b4 release with these options works fine. Of course, it's not very useful. :) Also verified that httpd.conf did not contain additional load_module calls. I do not install any disto software for php/apache/mysql/etc and control all of this by building from source. Josh [2004-03-09 08:43:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip And try this for PHP: # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Also, make sure you're NOT loading any other PHP versions the same time in your apache httpd.conf (some distros come with preinstalled PHP, so..) ---- [2004-03-08 15:51:25] josh at netbits dot us Description: I compiled php 5.0.0b4 on a SuSE linux system. uname -a: Linux langly 2.4.19-4GB #1 Mon Aug 4 23:38:42 UTC 2003 i686 unknown gcc -v: Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.2 The configure command used the following options: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs \ \ --enable-exif \ --enable-ftp \ --enable-sockets \ --with-mcrypt \ --with-mhash \ --with-openssl \ --with-iconv \ --with-ncurses \ --with-readline \ --with-curl \ \ --with-bz2 \ --with-zip \ --with-zlib \ \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/usr/local/mysql/mysql.sock \ \ --with-pgsql=/usr/local/pgsql \ \ --with-oci8 \ \ --with-sqlite \ \ --with-gd \ --with-ttf \ --with-freetype \ --with-freetype-dir=/usr/X11/lib \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr \ \ --enable-xml \ --enable-wddx \ --with-xsl \ --with-expat-dir=/usr \ --with-libxml-dir=/usr/local \ --with-xmlrpc \ --with-dom \ --with-qtdom \ \ --with-java=/usr/local/java/ After installation and restarting apache (2.0.48), only one apache process is spawned - no additional threads are started. Attempts to access web pages with or without PhP hang until timing out - no messages are generated in the Apache error or access log. Single Apache process needs to be killed with kill -9. Re-instating PhP-4.3.4 module causes behavior to return to normal. ldd /usr/local/apache/modules/libphp5.so libcrypt.so.1 => /lib/libcrypt.so.1 (0x402a7000) libexslt.so.0 => /usr/local/lib/libexslt.so.0 (0x402d8000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402e7000) libhistory.so.4 => /lib/libhistory.so.4 (0x40307000) libreadline.so.4 => /lib/libreadline.so.4 (0x4030f000) libncurses.so.5 => /lib/libncurses.so.5 (0x4033b000) libpq.so.3 => /usr/local/pgsql-7.4.1/lib/libpq.so.3 (0x4037e000) libpanel.so.5 => /usr/lib/libpanel.so.5 (0x40398000) libmysqlclient.so.14 => /usr/local/mysql-5.0.0-alpha/lib/mysql/libmysqlclient.so.14 (0x4039c000) libmhash.so.2 => /usr/lib/libmhash.so.2 (0x40484000) libmcrypt.so.4 => /usr/local/lib/libmcrypt.so.4 (0x404a6000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x404db000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404e2000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40524000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4061c000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4062b000) libz.so.1 => /lib/libz.so.1 (0x4065b000) libjpeg.so.62 => /usr/lib/lib
#27528 [NoF->Opn]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
ID: 27528 User updated by: josh at netbits dot us Reported By: josh at netbits dot us -Status: No Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux SuSE 8.1 -PHP Version: 5.0.0b4 (beta4) +PHP Version: 5.0.0RC1 New Comment: Changed version to 5.0.0RC1 Previous Comments: [2004-03-23 13:39:43] josh at trutwins dot homeip dot net Also, noticed the following in php error log: [23-Mar-2004 12:39:03] PHP Warning: PHP Startup: [EMAIL PROTECTED]@: Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=0 PHPcompiled with module API=20040316, debug=0, thread-safety=0 These options need to match in Unknown on line 0 This was tried with the following configure options. ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs [2004-03-15 08:38:03] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2004-03-09 18:29:57] [EMAIL PROTECTED] Please isolate the problem to a particular module (by adding 1 module at a time to your configure). [2004-03-09 11:59:36] josh at netbits dot us Forgot, I also tried my original configure commands with CVS snapshot from yesterday afternoon - same results. [2004-03-09 11:58:15] josh at netbits dot us # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Using the php-5.0.0b4 release with these options works fine. Of course, it's not very useful. :) Also verified that httpd.conf did not contain additional load_module calls. I do not install any disto software for php/apache/mysql/etc and control all of this by building from source. Josh 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/27528 -- Edit this bug report at http://bugs.php.net/?id=27528&edit=1
#27684 [NEW]: attached files are missing bytes
From: josh at jamisonadvertising dot com Operating system: RedHat PHP version: 4.3.4 PHP Bug Type: *Mail Related Bug description: attached files are missing bytes Description: When using this class file: http://www.phpguru.org/ mime.mail.html to send mail with MIME attachments, the attachment comes through with bytes missing. This happens in both 4.3.3 and 4.3.4. I installed the identical code on a box running 4.2.3 (both boxes RedHat Linux with Apache) and the attachments came through intact. I had seen this described in a previous bug report here: http://bugs.php.net/bug.php?id=26061, but we updated the 4.3.4 version to the latest snapshot and the problem persists. Reproduce code: --- http://www.phpguru.org/mime.mail.html Expected result: Use the example.1.php file, and you will see that the attached zip file is corrupted. Actual result: -- Attached files are missing bytes. -- Edit bug report at http://bugs.php.net/?id=27684&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27684&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27684&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27684&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27684&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27684&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27684&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27684&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27684&r=support Expected behavior: http://bugs.php.net/fix.php?id=27684&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27684&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27684&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27684&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27684&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27684&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27684&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27684&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27684&r=float
#27528 [Bgs]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
ID: 27528 User updated by: josh at netbits dot us Reported By: josh at netbits dot us Status: Bogus Bug Type: Apache2 related Operating System: Linux SuSE 8.1 PHP Version: 5.0.0RC1 New Comment: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs Which of these options would cause: "User error, loading an old extension compiled with some older PHP version". Based on the configure used above, there are no "extensions" being built into this fresh compilation of PhP. Last I checked, php was an interpreted language, not a compiler, how would I "compile with some older PHP version"? I'd be willing to accept this bug being attributed to "user error" with a little more explanation of why instead of "of course it won't work". Previous Comments: [2004-04-07 04:52:22] [EMAIL PROTECTED] User error, loading an old extension compiled with some older PHP version -> OF COURSE it won't work.. [2004-03-23 13:39:43] josh at trutwins dot homeip dot net Also, noticed the following in php error log: [23-Mar-2004 12:39:03] PHP Warning: PHP Startup: [EMAIL PROTECTED]@: Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=0 PHPcompiled with module API=20040316, debug=0, thread-safety=0 These options need to match in Unknown on line 0 This was tried with the following configure options. ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs [2004-03-09 18:29:57] [EMAIL PROTECTED] Please isolate the problem to a particular module (by adding 1 module at a time to your configure). [2004-03-09 11:59:36] josh at netbits dot us Forgot, I also tried my original configure commands with CVS snapshot from yesterday afternoon - same results. [2004-03-09 11:58:15] josh at netbits dot us # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Using the php-5.0.0b4 release with these options works fine. Of course, it's not very useful. :) Also verified that httpd.conf did not contain additional load_module calls. I do not install any disto software for php/apache/mysql/etc and control all of this by building from source. Josh 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/27528 -- Edit this bug report at http://bugs.php.net/?id=27528&edit=1
#28014 [NEW]: attached files are missing bytes
From: josh at jamisonadvertising dot com Operating system: Red Hat PHP version: 4.3.4 PHP Bug Type: *Mail Related Bug description: attached files are missing bytes Description: I reported this bug before, only to have one of your developers dissmiss it as bogus and an issue for PHP support which is pretty damned insulting. I would appreciate it if someone could try the referenced class file and see if they aren't able to reproduce the error. Mail sent using mail() with attached files sends the mail, but the attached file arrives with bytes missing. I believe this to be a bug because the identical code (note the usage of the word IDENTITICAL) works on a box running 4.2.3 This particular installation of PHP was compiled with: './configure' '--with-apache=../apache_1.3.29' '--with- mysql=/usr/local/mysql' '--enable-memory-limit=yes' '-- enable-debug=no' '-with-mcrypt' '--enable-ftp' '-- enable-exif' '--enable-bcmath' '--with-xml' '--with- pspell' '--with-pgsql' '--with-mhash' '--with-ming' '-- with-curl' '--with-gd' '--enable-gd-native-ttf' '-- enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local/lib' '--with-png' '--with-zlib' '--with-freetype-dir=/usr/ local/include/freetype2' '--with-ttf' '--with-pdflib' '--with-tiff-dir=/usr/local/lib' Reproduce code: --- This is the second of two mail class files that produces the error on 4.3.4 or greater: http://phpmailer.sourceforge.net/ Expected result: On 4.2.3, mail will arrive with an intact attachment. On 4.3.4 or greater, the mail will arrive with an attachment with bytes missing. -- Edit bug report at http://bugs.php.net/?id=28014&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28014&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28014&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28014&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28014&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28014&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28014&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28014&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28014&r=support Expected behavior: http://bugs.php.net/fix.php?id=28014&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28014&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28014&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28014&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28014&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28014&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28014&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28014&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28014&r=float
#28014 [Bgs]: attached files are missing bytes
ID: 28014 User updated by: josh at jamisonadvertising dot com Reported By: josh at jamisonadvertising dot com Status: Bogus Bug Type: *Mail Related Operating System: Red Hat PHP Version: 4.3.4 New Comment: OK - I'll try that. Thank you for a much more helpful suggestion than the last one. Previous Comments: [2004-04-15 18:31:15] [EMAIL PROTECTED] I'm sorry you're having problems, but it's really a lot of work to download software and create test cases for bug reports. (It's not like we write those classes and we get lots of bugs each day.) Why don't you report the problem to the authors of the mail class and see if they can reproduce it? If they can, they will be able to generate a PHP bug report that makes it easier for us to fix the problem. ---- [2004-04-15 18:24:40] josh at jamisonadvertising dot com Description: I reported this bug before, only to have one of your developers dissmiss it as bogus and an issue for PHP support which is pretty damned insulting. I would appreciate it if someone could try the referenced class file and see if they aren't able to reproduce the error. Mail sent using mail() with attached files sends the mail, but the attached file arrives with bytes missing. I believe this to be a bug because the identical code (note the usage of the word IDENTITICAL) works on a box running 4.2.3 This particular installation of PHP was compiled with: './configure' '--with-apache=../apache_1.3.29' '--with- mysql=/usr/local/mysql' '--enable-memory-limit=yes' '-- enable-debug=no' '-with-mcrypt' '--enable-ftp' '-- enable-exif' '--enable-bcmath' '--with-xml' '--with- pspell' '--with-pgsql' '--with-mhash' '--with-ming' '-- with-curl' '--with-gd' '--enable-gd-native-ttf' '-- enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local/lib' '--with-png' '--with-zlib' '--with-freetype-dir=/usr/ local/include/freetype2' '--with-ttf' '--with-pdflib' '--with-tiff-dir=/usr/local/lib' Reproduce code: --- This is the second of two mail class files that produces the error on 4.3.4 or greater: http://phpmailer.sourceforge.net/ Expected result: On 4.2.3, mail will arrive with an intact attachment. On 4.3.4 or greater, the mail will arrive with an attachment with bytes missing. -- Edit this bug report at http://bugs.php.net/?id=28014&edit=1
#28014 [Bgs]: attached files are missing bytes
ID: 28014 User updated by: josh at jamisonadvertising dot com Reported By: josh at jamisonadvertising dot com Status: Bogus Bug Type: *Mail Related Operating System: Red Hat PHP Version: 4.3.4 New Comment: OK - well I found the problem. magic_quotes_runtime I'll post something in the mail() function. Previous Comments: [2004-04-15 18:36:25] josh at jamisonadvertising dot com OK - I'll try that. Thank you for a much more helpful suggestion than the last one. [2004-04-15 18:31:15] [EMAIL PROTECTED] I'm sorry you're having problems, but it's really a lot of work to download software and create test cases for bug reports. (It's not like we write those classes and we get lots of bugs each day.) Why don't you report the problem to the authors of the mail class and see if they can reproduce it? If they can, they will be able to generate a PHP bug report that makes it easier for us to fix the problem. ---- [2004-04-15 18:24:40] josh at jamisonadvertising dot com Description: I reported this bug before, only to have one of your developers dissmiss it as bogus and an issue for PHP support which is pretty damned insulting. I would appreciate it if someone could try the referenced class file and see if they aren't able to reproduce the error. Mail sent using mail() with attached files sends the mail, but the attached file arrives with bytes missing. I believe this to be a bug because the identical code (note the usage of the word IDENTITICAL) works on a box running 4.2.3 This particular installation of PHP was compiled with: './configure' '--with-apache=../apache_1.3.29' '--with- mysql=/usr/local/mysql' '--enable-memory-limit=yes' '-- enable-debug=no' '-with-mcrypt' '--enable-ftp' '-- enable-exif' '--enable-bcmath' '--with-xml' '--with- pspell' '--with-pgsql' '--with-mhash' '--with-ming' '-- with-curl' '--with-gd' '--enable-gd-native-ttf' '-- enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local/lib' '--with-png' '--with-zlib' '--with-freetype-dir=/usr/ local/include/freetype2' '--with-ttf' '--with-pdflib' '--with-tiff-dir=/usr/local/lib' Reproduce code: --- This is the second of two mail class files that produces the error on 4.3.4 or greater: http://phpmailer.sourceforge.net/ Expected result: On 4.2.3, mail will arrive with an intact attachment. On 4.3.4 or greater, the mail will arrive with an attachment with bytes missing. -- Edit this bug report at http://bugs.php.net/?id=28014&edit=1
Bug #60462 [Com]: When APC is enabled segfault
Edit report at https://bugs.php.net/bug.php?id=60462&edit=1 ID: 60462 Comment by: josh at joshbutts dot com Reported by:henrik at bjrnskov dot dk Summary:When APC is enabled segfault Status: Open Type: Bug Package:FPM related Operating System: Mac OS X 10.7 PHP Version:5.4.0RC2 Block user comment: N Private report: N New Comment: Happens also in 5.4RC5 with APC from pecl on OSX 10.7.3 Previous Comments: [2011-12-28 15:50:26] henrik at bjrnskov dot dk Just tried compiling a 5.4RC4 manually and installing apc from svn and pecl. both php-fpm and apache2 module segfaults. OS X Lion 10.7.3 [2011-12-17 11:14:35] lolautruche at gmail dot com Here : http://svn.php.net/repository/pecl/apc/ [2011-12-17 11:10:53] henrik at bjrnskov dot dk Where is apc svn ? [2011-12-16 17:55:26] lolautruche at gmail dot com no more segfault with latest php 5.4 build and APC built from trunk [2011-12-16 17:34:04] lolautruche at gmail dot com Hi I also experience this issue on Linux Ubuntu Server 8.04 LTS 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 https://bugs.php.net/bug.php?id=60462 -- Edit this bug report at https://bugs.php.net/bug.php?id=60462&edit=1
Bug #36947 [Com]: HTTP stream wrapper does not treat all 2xx status codes as successful
Edit report at https://bugs.php.net/bug.php?id=36947&edit=1 ID: 36947 Comment by: josh at joshbutts dot com Reported by:Jared dot Williams1 at ntlworld dot com Summary:HTTP stream wrapper does not treat all 2xx status codes as successful Status: Open Type: Bug Package:Streams related Operating System: Win2000 PHP Version:5.1.3RC2 Block user comment: N Private report: N New Comment: This does not appear to be fixed in 5.3.6 compiled from source on Mac OS 10.7 Previous Comments: [2008-10-27 11:59:01] bj...@php.net Fixed in PHP5.3, but I don't think it has been documented properly yet. See: http://php.markmail.org/message/5rockhlt6hj7tzrb [2006-04-02 13:39:17] Jared dot Williams1 at ntlworld dot com Was raised on php internals ~year ago.. http://marc.theaimsgroup.com/?l=php-dev&m=111383344601864&w=2 http://marc.theaimsgroup.com/?l=php-dev&m=111384113712112&w=2 http://marc.theaimsgroup.com/?l=php-dev&m=111384249807034&w=2 [2006-04-02 13:20:04] Jared dot Williams1 at ntlworld dot com Description: PHP HTTP stream wrapper does not treat all http 2xx status codes as successful, making it impossible to use with WebDAV. -- Edit this bug report at https://bugs.php.net/bug.php?id=36947&edit=1
Bug #46035 [Com]: fopen() fails to open successful HTTP 207 Multi-Status response
Edit report at https://bugs.php.net/bug.php?id=46035&edit=1
ID: 46035
Comment by: josh at joshbutts dot com
Reported by:ms419 at freezone dot co dot uk
Summary:fopen() fails to open successful HTTP 207
Multi-Status response
Status: Closed
Type: Bug
Package:Streams related
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
This does not appear to be fixed in 5.3.6 compiled from source on Mac OS 10.7
Previous Comments:
[2008-10-18 18:15:14] fel...@php.net
This bug has been fixed in PHP 5.3.
[2008-09-17 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-09-10 00:58:44] il...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
Seems to work just fine here...
[2008-09-09 23:35:40] ms419 at freezone dot co dot uk
Description:
I am working on a PHP interface to WebDAV repositories using fopen(). I use
fopen() to make a PROPFIND request to the server, hoping to use DOM to parse
the result. Unfortunately fopen() fails even on successful responses from the
server
Reproduce code:
---
http://qubit-toolkit.googlecode.com/svn/trunk/';
$context = stream_context_create(array('http' => array(
'method' => 'PROPFIND',
'header' => 'Depth: 1')));
$handle = fopen($filename, 'r', false, $context);
var_dump($handle);
Expected result:
$handle should be a resource from which I can read the server's successful
response:
PROPFIND /svn/trunk/ HTTP/1.0
Host: qubit-toolkit.googlecode.com
Depth: 1
HTTP/1.0 207 Multi-Status
Date: Tue, 09 Sep 2008 23:34:32 GMT
Server: Apache
Content-Type: text/xml; charset="utf-8"
Connection: Close
http://subversion.tigris.org/xmlns/svn/"; xmlns:C="http://su
bversion.tigris.org/xmlns/custom/" xmlns:V="http://subversion.tigris.org/xmlns/d
av/" xmlns:lp1="DAV:" xmlns:lp3="http://subversion.tigris.org/xmlns/dav/"; xmlns:
lp2="http://apache.org/dav/props/";>
/svn/trunk/
[...]
Actual result:
--
ket% php fopen.php
Warning: fopen(http://qubit-toolkit.googlecode.com/svn/trunk/): failed to open
stream: HTTP request failed! HTTP/1.0 207 Multi-Status
in /home/jablko/public_html/fopen.php on line 7
bool(false)
ket%
--
Edit this bug report at https://bugs.php.net/bug.php?id=46035&edit=1
[PHP-BUG] Bug #65226 [NEW]: chroot() does not get enabled
From: josh at servebyte dot com
Operating system: Debian 7
PHP version: 5.5.0
Package: CGI/CLI related
Bug Type: Bug
Bug description:chroot() does not get enabled
Description:
PHP Fatal error: Call to undefined function chroot() in Command line code
on line 1
During the configure process it states that chroot is available: "checking
for chroot... yes"
The php version: "PHP 5.5.0 (cli) (built: Jul 9 2013 15:30:23)"
The user is root.
As per the documentation, these are the only requirements. Perhaps I
missing a configure variable? I have tested with just "./configure" with no
params to ensure nothing else is interfering.
Thread safety is disabled: "checking whether to enable thread-safety... no"
Test script:
---
php -r "chroot('/var/chroot/');"
Expected result:
The chroot function should be available
Actual result:
--
The chroot function is excluded from the PHP build
--
Edit bug report at https://bugs.php.net/bug.php?id=65226&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65226&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65226&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65226&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65226&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65226&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65226&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65226&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65226&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65226&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65226&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65226&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65226&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65226&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65226&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65226&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65226&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65226&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65226&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65226&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65226&r=mysqlcfg
Bug #65226 [Com]: chroot() does not get enabled
Edit report at https://bugs.php.net/bug.php?id=65226&edit=1
ID: 65226
Comment by: josh at servebyte dot com
Reported by:josh at servebyte dot com
Summary:chroot() does not get enabled
Status: Open
Type: Bug
Package:CGI/CLI related
Operating System: Debian 7
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Seems to work fine with PHP 5.3
# php -r "chroot();"
Warning: chroot() expects exactly 1 parameter, 0 given in Command line code on
line 1
PHP 5.3.26 (cli) (built: Jul 10 2013 16:52:53)
Previous Comments:
[2013-07-09 14:37:59] josh at servebyte dot com
Description:
PHP Fatal error: Call to undefined function chroot() in Command line code on
line 1
During the configure process it states that chroot is available: "checking for
chroot... yes"
The php version: "PHP 5.5.0 (cli) (built: Jul 9 2013 15:30:23)"
The user is root.
As per the documentation, these are the only requirements. Perhaps I missing a
configure variable? I have tested with just "./configure" with no params to
ensure nothing else is interfering.
Thread safety is disabled: "checking whether to enable thread-safety... no"
Test script:
---
php -r "chroot('/var/chroot/');"
Expected result:
The chroot function should be available
Actual result:
--
The chroot function is excluded from the PHP build
--
Edit this bug report at https://bugs.php.net/bug.php?id=65226&edit=1
Bug #65226 [Com]: chroot() does not get enabled
Edit report at https://bugs.php.net/bug.php?id=65226&edit=1
ID: 65226
Comment by: josh at servebyte dot com
Reported by:josh at servebyte dot com
Summary:chroot() does not get enabled
Status: Open
Type: Bug
Package:CGI/CLI related
Operating System: Debian 7
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
PHP 5.3... during the configure $PHP_SAPI is set to: cgi
PHP 5.5... during the configure $PHP_SAPI is set to: none
Previous Comments:
[2013-07-10 16:43:08] josh at servebyte dot com
However the problem is in PHP 5.4 too
#php -r "chroot();"
Fatal error: Call to undefined function chroot() in Command line code on line 1
PHP 5.4.17 (cli) (built: Jul 10 2013 17:36:53)
[2013-07-10 16:00:25] josh at servebyte dot com
Seems to work fine with PHP 5.3
# php -r "chroot();"
Warning: chroot() expects exactly 1 parameter, 0 given in Command line code on
line 1
PHP 5.3.26 (cli) (built: Jul 10 2013 16:52:53)
----
[2013-07-09 14:37:59] josh at servebyte dot com
Description:
PHP Fatal error: Call to undefined function chroot() in Command line code on
line 1
During the configure process it states that chroot is available: "checking for
chroot... yes"
The php version: "PHP 5.5.0 (cli) (built: Jul 9 2013 15:30:23)"
The user is root.
As per the documentation, these are the only requirements. Perhaps I missing a
configure variable? I have tested with just "./configure" with no params to
ensure nothing else is interfering.
Thread safety is disabled: "checking whether to enable thread-safety... no"
Test script:
---
php -r "chroot('/var/chroot/');"
Expected result:
The chroot function should be available
Actual result:
--
The chroot function is excluded from the PHP build
--
Edit this bug report at https://bugs.php.net/bug.php?id=65226&edit=1
Bug #65226 [Com]: chroot() does not get enabled
Edit report at https://bugs.php.net/bug.php?id=65226&edit=1
ID: 65226
Comment by: josh at servebyte dot com
Reported by:josh at servebyte dot com
Summary:chroot() does not get enabled
Status: Open
Type: Bug
Package:CGI/CLI related
Operating System: Debian 7
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
However the problem is in PHP 5.4 too
#php -r "chroot();"
Fatal error: Call to undefined function chroot() in Command line code on line 1
PHP 5.4.17 (cli) (built: Jul 10 2013 17:36:53)
Previous Comments:
[2013-07-10 16:00:25] josh at servebyte dot com
Seems to work fine with PHP 5.3
# php -r "chroot();"
Warning: chroot() expects exactly 1 parameter, 0 given in Command line code on
line 1
PHP 5.3.26 (cli) (built: Jul 10 2013 16:52:53)
----
[2013-07-09 14:37:59] josh at servebyte dot com
Description:
PHP Fatal error: Call to undefined function chroot() in Command line code on
line 1
During the configure process it states that chroot is available: "checking for
chroot... yes"
The php version: "PHP 5.5.0 (cli) (built: Jul 9 2013 15:30:23)"
The user is root.
As per the documentation, these are the only requirements. Perhaps I missing a
configure variable? I have tested with just "./configure" with no params to
ensure nothing else is interfering.
Thread safety is disabled: "checking whether to enable thread-safety... no"
Test script:
---
php -r "chroot('/var/chroot/');"
Expected result:
The chroot function should be available
Actual result:
--
The chroot function is excluded from the PHP build
--
Edit this bug report at https://bugs.php.net/bug.php?id=65226&edit=1
Bug #65226 [Com]: chroot() does not get enabled
Edit report at https://bugs.php.net/bug.php?id=65226&edit=1
ID: 65226
Comment by: josh at servebyte dot com
Reported by:josh at servebyte dot com
Summary:chroot() does not get enabled
Status: Feedback
Type: Bug
Package:CGI/CLI related
Operating System: Debian 7
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
There's no file called config.nice in the 5.5.0 tar?
./configure | grep chroot
checking for chroot... yes
I can get it working by editing the configure file and commenting these lines
like so;
if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $
$as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h
fi
to
#if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $
$as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h
#fi
The variable $PHP_SAPI is set to "none" so it seems to be a configure bug of
some sort.
Previous Comments:
[2013-07-10 17:09:48] a...@php.net
#if defined(HAVE_CHROOT) && !defined(ZTS) && ENABLE_CHROOT_FUNC
thats what has to match.
please post the output of
./config.nice | grep chroot
[2013-07-10 16:51:01] josh at servebyte dot com
PHP 5.3... during the configure $PHP_SAPI is set to: cgi
PHP 5.5... during the configure $PHP_SAPI is set to: none
[2013-07-10 16:43:08] josh at servebyte dot com
However the problem is in PHP 5.4 too
#php -r "chroot();"
Fatal error: Call to undefined function chroot() in Command line code on line 1
PHP 5.4.17 (cli) (built: Jul 10 2013 17:36:53)
[2013-07-10 16:00:25] josh at servebyte dot com
Seems to work fine with PHP 5.3
# php -r "chroot();"
Warning: chroot() expects exactly 1 parameter, 0 given in Command line code on
line 1
PHP 5.3.26 (cli) (built: Jul 10 2013 16:52:53)
[2013-07-09 14:37:59] josh at servebyte dot com
Description:
PHP Fatal error: Call to undefined function chroot() in Command line code on
line 1
During the configure process it states that chroot is available: "checking for
chroot... yes"
The php version: "PHP 5.5.0 (cli) (built: Jul 9 2013 15:30:23)"
The user is root.
As per the documentation, these are the only requirements. Perhaps I missing a
configure variable? I have tested with just "./configure" with no params to
ensure nothing else is interfering.
Thread safety is disabled: "checking whether to enable thread-safety... no"
Test script:
---
php -r "chroot('/var/chroot/');"
Expected result:
The chroot function should be available
Actual result:
--
The chroot function is excluded from the PHP build
--
Edit this bug report at https://bugs.php.net/bug.php?id=65226&edit=1
Bug #65226 [Com]: chroot() does not get enabled
Edit report at https://bugs.php.net/bug.php?id=65226&edit=1 ID: 65226 Comment by: josh at servebyte dot com Reported by:josh at servebyte dot com Summary:chroot() does not get enabled Status: Feedback Type: Bug Package:CGI/CLI related Operating System: Debian 7 PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Adding "--enable-cgi --enable-cli" to configure didn't change anything. $PHP_SAPI is in A LOT of files. I don't know where to start looking for it. :( Previous Comments: [2013-07-10 17:40:46] a...@php.net That's clear that you can trick it to out the desired define :) ... Ok, i also see 'checking for chroot ... yes', but i do --enable-cgi --enable-cli too, not just ./configure . That might be the difference. Haven't looked where PHP_SAPI is set, you could debug it. config.nice is created once ./configure was run, so you don't have to type all the options again. ---- [2013-07-10 17:24:46] josh at servebyte dot com There's no file called config.nice in the 5.5.0 tar? ./configure | grep chroot checking for chroot... yes I can get it working by editing the configure file and commenting these lines like so; if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $ $as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h fi to #if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $ $as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h #fi The variable $PHP_SAPI is set to "none" so it seems to be a configure bug of some sort. [2013-07-10 17:09:48] a...@php.net #if defined(HAVE_CHROOT) && !defined(ZTS) && ENABLE_CHROOT_FUNC thats what has to match. please post the output of ./config.nice | grep chroot [2013-07-10 16:51:01] josh at servebyte dot com PHP 5.3... during the configure $PHP_SAPI is set to: cgi PHP 5.5... during the configure $PHP_SAPI is set to: none [2013-07-10 16:43:08] josh at servebyte dot com However the problem is in PHP 5.4 too #php -r "chroot();" Fatal error: Call to undefined function chroot() in Command line code on line 1 PHP 5.4.17 (cli) (built: Jul 10 2013 17:36:53) 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 https://bugs.php.net/bug.php?id=65226 -- Edit this bug report at https://bugs.php.net/bug.php?id=65226&edit=1
Bug #65226 [Com]: chroot() does not get enabled
Edit report at https://bugs.php.net/bug.php?id=65226&edit=1 ID: 65226 Comment by: josh at servebyte dot com Reported by:josh at servebyte dot com Summary:chroot() does not get enabled Status: Closed Type: Bug Package:CGI/CLI related Operating System: Debian 7 PHP Version:5.5.0 Assigned To:ab Block user comment: N Private report: N New Comment: I tested both the PHP 5.4 and 5.5 git branches and can confirm that this is fixed. I used this command for testing: ./configure --prefix=/opt/php/5.x Thank you very much! Previous Comments: [2013-07-10 22:56:13] a...@php.net Please test on 5.4+ git. You still have to disable any SAPI other than CLI/CGI/embed for that to work. [2013-07-10 22:52:59] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=2acc38627092123ac462f3a23780bf887bf69286 Log: Fixed bug #65226 chroot() does not get enabled [2013-07-10 19:18:27] josh at servebyte dot com Adding "--enable-cgi --enable-cli" to configure didn't change anything. $PHP_SAPI is in A LOT of files. I don't know where to start looking for it. :( [2013-07-10 17:40:46] a...@php.net That's clear that you can trick it to out the desired define :) ... Ok, i also see 'checking for chroot ... yes', but i do --enable-cgi --enable-cli too, not just ./configure . That might be the difference. Haven't looked where PHP_SAPI is set, you could debug it. config.nice is created once ./configure was run, so you don't have to type all the options again. ---- [2013-07-10 17:24:46] josh at servebyte dot com There's no file called config.nice in the 5.5.0 tar? ./configure | grep chroot checking for chroot... yes I can get it working by editing the configure file and commenting these lines like so; if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $ $as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h fi to #if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $ $as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h #fi The variable $PHP_SAPI is set to "none" so it seems to be a configure bug of some sort. 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 https://bugs.php.net/bug.php?id=65226 -- Edit this bug report at https://bugs.php.net/bug.php?id=65226&edit=1
#48573 [NEW]: E-notated strings improperly cast as integers
From: josh at mykoala dot com Operating system: Mac OS X 10.5.7 PHP version: 5.2.9 PHP Bug Type: *Programming Data Structures Bug description: E-notated strings improperly cast as integers Description: When an E notated integer is in a string, and you try to cast it to an integer, the value stops at anything non-integer, reducing the ability to cast notated numbers. It does not first check or convert the value to a float to account for E notation. The documentation on type juggling doesn't mention this limitation, and it is not the expected result. Reproduce code: --- $ php -r 'var_dump((int)"5.6401418785e+05");' int(5) $ php -r 'var_dump((int)5.6401418785e+05);' int(564014) $ php -r 'var_dump((int)(float)"5.6401418785e+05");' int(564014) -- Edit bug report at http://bugs.php.net/?id=48573&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48573&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48573&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48573&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48573&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48573&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48573&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48573&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48573&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48573&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48573&r=support Expected behavior: http://bugs.php.net/fix.php?id=48573&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48573&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48573&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48573&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48573&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48573&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48573&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48573&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48573&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48573&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48573&r=mysqlcfg
#48573 [Opn]: E-notated strings improperly cast as integers
ID: 48573 User updated by: josh at mykoala dot com Reported By: josh at mykoala dot com Status: Open Bug Type: *Programming Data Structures Operating System: Mac OS X 10.5.7 PHP Version: 5.2.9 New Comment: > When an E notated integer When an E notated float* intval() on the string also (predictably) produces the same result as casting to int Previous Comments: [2009-06-16 19:08:10] josh at mykoala dot com Description: When an E notated integer is in a string, and you try to cast it to an integer, the value stops at anything non-integer, reducing the ability to cast notated numbers. It does not first check or convert the value to a float to account for E notation. The documentation on type juggling doesn't mention this limitation, and it is not the expected result. Reproduce code: --- $ php -r 'var_dump((int)"5.6401418785e+05");' int(5) $ php -r 'var_dump((int)5.6401418785e+05);' int(564014) $ php -r 'var_dump((int)(float)"5.6401418785e+05");' int(564014) -- Edit this bug report at http://bugs.php.net/?id=48573&edit=1
#48573 [Opn]: E-notated strings improperly cast as integers
ID: 48573 User updated by: josh at mykoala dot com Reported By: josh at mykoala dot com Status: Open Bug Type: Scripting Engine problem Operating System: Mac OS X 10.5.7 PHP Version: 5.2.9 New Comment: Well, round() produces the desired result -- the large number without any decimals. Adding zero just casts to float, which takes the decimals into consideration, and is the same as: $ php -r 'var_dump((float)"5.6401418785e+05");' float(564014.18785) It's that conversion to int directly that makes Iron Eyes Cody cry. Previous Comments: [2009-06-23 19:57:29] sjoerd-php at linuxonly dot nl Thank you for your bug report. A workaround for what you want is adding 0: php -r 'echo 0 + "5.6401418785e+05";' 564014.18785 ---- [2009-06-16 19:54:37] josh at mykoala dot com > When an E notated integer When an E notated float* intval() on the string also (predictably) produces the same result as casting to int [2009-06-16 19:08:10] josh at mykoala dot com Description: When an E notated integer is in a string, and you try to cast it to an integer, the value stops at anything non-integer, reducing the ability to cast notated numbers. It does not first check or convert the value to a float to account for E notation. The documentation on type juggling doesn't mention this limitation, and it is not the expected result. Reproduce code: --- $ php -r 'var_dump((int)"5.6401418785e+05");' int(5) $ php -r 'var_dump((int)5.6401418785e+05);' int(564014) $ php -r 'var_dump((int)(float)"5.6401418785e+05");' int(564014) -- Edit this bug report at http://bugs.php.net/?id=48573&edit=1
#49737 [NEW]: LDAP doesn't work from Apache 2.0 module but does from CLI
From: josh at endries dot org Operating system: RHEL4 PHP version: 5.2.11 PHP Bug Type: LDAP related Bug description: LDAP doesn't work from Apache 2.0 module but does from CLI Description: I'm trying to connect to LDAP using SSL or TLS but it doesn't work when run through the Apache 2 module. It appears to work fine when run via the CLI. I'm using the same exact code in each script. Using strace I can see the script read ldap.conf and the CA files, but with the module (connecting to the httpd process) it doesn't read any files. It dies after trying to verify the CA. I have a real cert and my CA is in /etc/openldap/cacerts, but of course if these (or anything else) isn't read in, it wouldn't be trusted. Using TLS or SSL doesn't matter, nor does using a URI instead of hostname/port pair. I have recompiled to make sure they both use the same libraries, and I have "TLS_REQCERT never" in /etc/openldap/ldap.conf, which are the suggestions I found online. Reproduce code: --- http://bugs.php.net/?id=49737&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49737&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49737&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49737&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49737&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49737&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49737&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49737&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49737&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49737&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49737&r=support Expected behavior: http://bugs.php.net/fix.php?id=49737&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49737&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49737&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49737&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49737&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49737&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49737&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49737&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49737&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49737&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49737&r=mysqlcfg
#49737 [Com]: LDAP doesn't work from Apache 2.0 module but does from CLI
ID: 49737 Comment by: josh at endries dot org Reported By: josh at endries dot org Status: Feedback Bug Type: LDAP related Operating System: RHEL4 PHP Version: 5.2.11 New Comment: Thanks for the response. I'm sure. I've reinstalled a few times, with the same configuration as when I initially ran into this, and I even went through an upgrade from 5.2.10 to 5.2.11. The version number did change in both, but it didn't affect this issue. Comparing ldd and strings output suggests they're from the same build also. The build date, configure command, and everything else I looked at in phpinfo() for CLI and the module is identical. Previous Comments: [2009-10-01 16:08:42] j...@php.net And you're absolutely sure both CLI and apache module are same version compiled with same options? Check this from phpinfo(). Also check the PHP Version.. ---- [2009-10-01 15:26:55] josh at endries dot org Description: I'm trying to connect to LDAP using SSL or TLS but it doesn't work when run through the Apache 2 module. It appears to work fine when run via the CLI. I'm using the same exact code in each script. Using strace I can see the script read ldap.conf and the CA files, but with the module (connecting to the httpd process) it doesn't read any files. It dies after trying to verify the CA. I have a real cert and my CA is in /etc/openldap/cacerts, but of course if these (or anything else) isn't read in, it wouldn't be trusted. Using TLS or SSL doesn't matter, nor does using a URI instead of hostname/port pair. I have recompiled to make sure they both use the same libraries, and I have "TLS_REQCERT never" in /etc/openldap/ldap.conf, which are the suggestions I found online. Reproduce code: --- http://bugs.php.net/?id=49737&edit=1
#49793 [NEW]: Max open files limit hit when specifying error_reporting in vhost config
From: josh at endries dot org Operating system: RHEL5 PHP version: 5.2.11 PHP Bug Type: Apache2 related Bug description: Max open files limit hit when specifying error_reporting in vhost config Description: When I specify "php_[admin_]value error_reporting #" in an Apache virtualhost, loading a page "instantly" fills up the open file descriptors with the PHP error_log. When I comment out that one line, everything works normally. I've used values from 32767 up to 100 but it doesn't seem to matter. If it's defined, my open files limit gets reached on the first request, or higher if the page is simply phpinfo(). Loading my index stops at 1008, the nfo.php script (which is just "http://bugs.php.net/?id=49793&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49793&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49793&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49793&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49793&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49793&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49793&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49793&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49793&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49793&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49793&r=support Expected behavior: http://bugs.php.net/fix.php?id=49793&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49793&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49793&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49793&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49793&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49793&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49793&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49793&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49793&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49793&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49793&r=mysqlcfg
#46265 [NEW]: DOMNode should have a property that checks if it exists
From: josh at coady dot us
Operating system: ubuntu 8.04.1
PHP version: 5.2.6
PHP Bug Type: DOM XML related
Bug description: DOMNode should have a property that checks if it exists
Description:
DOMNode should have a property like $exists to check if the node still
exists. This would be useful to avoid the "Node no longer exists" warning.
We should be able to do something like
$node->parentNode->removeChild($node);
if($node->exists)
{
// use node ..
}
Reproduce code:
---
$doc =
DOMDocument::loadXML('1110');
$nodes = $doc->getElementsByTagName('a');
$nodesToRemove = array();
foreach($nodes as $node)
{
if($node->nodeValue == 1)
{
$nodesToRemove[] = $node;
$node->parentNode->removeChild($node);
}
}
foreach($nodesToRemove as $node)
{
$node->parentNode->removeChild($node);
}
Expected result:
This is more of a feature request. I expect to change the last loop to
something like
foreach($nodesToRemove as $node)
{
if($node->exists)
{
$node->parentNode->removeChild($node);
}
}
--
Edit bug report at http://bugs.php.net/?id=46265&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46265&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46265&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46265&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46265&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46265&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46265&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46265&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46265&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46265&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46265&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46265&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46265&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46265&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46265&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46265&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46265&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46265&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46265&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46265&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46265&r=mysqlcfg
#46265 [Opn]: DOMNode should have a property that checks if it exists
ID: 46265
User updated by: josh at coady dot us
Reported By: josh at coady dot us
Status: Open
Bug Type: DOM XML related
Operating System: ubuntu 8.04.1
PHP Version: 5.2.6
New Comment:
reproduce code should be the following (I realized the code wasnt
duplicating the exact situation I was encountering, so I modified it to
better match)
$doc =
DOMDocument::loadXML('1110');
$nodes = $doc->getElementsByTagName('a');
$nodesToRemove = array();
foreach($nodes as $node)
{
if($node->nodeValue == 1)
{
$nodesToRemove[] = $node;
}
}
foreach($nodesToRemove as $node)
{
$node->parentNode->parentNode->removeChild($node->parentNode);
}
Previous Comments:
----
[2008-10-09 19:17:38] josh at coady dot us
Description:
DOMNode should have a property like $exists to check if the node still
exists. This would be useful to avoid the "Node no longer exists"
warning.
We should be able to do something like
$node->parentNode->removeChild($node);
if($node->exists)
{
// use node ..
}
Reproduce code:
---
$doc =
DOMDocument::loadXML('1110');
$nodes = $doc->getElementsByTagName('a');
$nodesToRemove = array();
foreach($nodes as $node)
{
if($node->nodeValue == 1)
{
$nodesToRemove[] = $node;
$node->parentNode->removeChild($node);
}
}
foreach($nodesToRemove as $node)
{
$node->parentNode->removeChild($node);
}
Expected result:
This is more of a feature request. I expect to change the last loop to
something like
foreach($nodesToRemove as $node)
{
if($node->exists)
{
$node->parentNode->removeChild($node);
}
}
--
Edit this bug report at http://bugs.php.net/?id=46265&edit=1
[PHP-BUG] Bug #53079 [NEW]: SSH2 randomly works along side MySQL
From: Operating system: CentOS 5.5 PHP version: 5.3.3 Package: Unknown/Other Function Bug Type: Bug Bug description:SSH2 randomly works along side MySQL Description: ssh2_exec and ssh2_shell functions randomly work. Expected result: These functions work perfectly when no MySQL connection is active. They should work when a MySQL connection is active too. Actual result: -- When a MySQL connection is active, the ssh2_exec and ssh2_shell functions randomly pick up on the MySQL stream, making the data returned from the ssh2_exec and ssh2_shell functions corrupt. I am guessing that there is a conflict between the 2 extensions. -- Edit bug report at http://bugs.php.net/bug.php?id=53079&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53079&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53079&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53079&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53079&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53079&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53079&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53079&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53079&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53079&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53079&r=support Expected behavior: http://bugs.php.net/fix.php?id=53079&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53079&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53079&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53079&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53079&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53079&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53079&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53079&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53079&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53079&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53079&r=mysqlcfg
Bug #53079 [Opn]: SSH2 randomly works along side MySQL
Edit report at http://bugs.php.net/bug.php?id=53079&edit=1 ID: 53079 User updated by:josh at servebyte dot com Reported by:josh at servebyte dot com Summary:SSH2 randomly works along side MySQL Status: Open Type: Bug Package:Unknown/Other Function Operating System: CentOS 5.5 PHP Version:5.3.3 Block user comment: N New Comment: ssh2 0.11.0 php 3.3.3 libssh2 1.2.7-1.el5.rf Previous Comments: [2010-10-15 23:25:07] josh at servebyte dot com Description: ssh2_exec and ssh2_shell functions randomly work. Expected result: These functions work perfectly when no MySQL connection is active. They should work when a MySQL connection is active too. Actual result: -- When a MySQL connection is active, the ssh2_exec and ssh2_shell functions randomly pick up on the MySQL stream, making the data returned from the ssh2_exec and ssh2_shell functions corrupt. I am guessing that there is a conflict between the 2 extensions. -- Edit this bug report at http://bugs.php.net/bug.php?id=53079&edit=1
Bug #50912 [Com]: can't install PDO-PGSQL
Edit report at http://bugs.php.net/bug.php?id=50912&edit=1 ID: 50912 Comment by: josh at endries dot org Reported by:michaelstrasser at tele2 dot at Summary:can't install PDO-PGSQL Status: Bogus Type: Bug Package:PDO related Operating System: Windows XP PHP Version:5.3SVN-2010-02-02 (snap) Block user comment: N New Comment: This buug entry is NOT bogus. I just installed PHP from the web site and get this same error. PDO PGSQL is *NOT* included. I will submit a new ticket to actually get this addressed properly. Previous Comments: [2010-02-03 19:51:10] paj...@php.net PDO PGSQL is part of the core distribution since years. Latest PHP releases include the PGSQL library and extensions, use them instead of PECL, on windows or source releases. [2010-02-03 19:33:39] jb at gmx dot at I think the source of the problem is that PHP 5.3 is not compatible with windows xp. Try using linux instead. [2010-02-02 13:38:08] michaelstrasser at tele2 dot at Description: Hi, I am using Windows XP with PHP 5.3 and I can't install PDO_PGSQL. This is what Pecl tells me: C:\Dokumente und Einstellungen\Michael>pecl install pdo_pgsql downloading PDO_PGSQL-1.0.2.tgz ... Starting to download PDO_PGSQL-1.0.2.tgz (14,961 bytes) .done: 14,961 bytes downloading PDO-1.0.3.tgz ... Starting to download PDO-1.0.3.tgz (52,613 bytes) ...done: 52,613 bytes 12 source files, building ERROR: The DSP PDO.dsp does not exist. 7 source files, building ERROR: The DSP PDO_PGSQL.dsp does not exist. Unfortunately the PECL site, where I could get snapshots of the extensions, is down. So I have no clue where to get the extension from. -- Edit this bug report at http://bugs.php.net/bug.php?id=50912&edit=1
Bug #50912 [Com]: can't install PDO-PGSQL
Edit report at http://bugs.php.net/bug.php?id=50912&edit=1 ID: 50912 Comment by: josh at endries dot org Reported by:michaelstrasser at tele2 dot at Summary:can't install PDO-PGSQL Status: Bogus Type: Bug Package:PDO related Operating System: Windows XP PHP Version:5.3SVN-2010-02-02 (snap) Block user comment: N New Comment: The correct (I think) answer to this problem is that the pecl binary doesn't work on Windows. Instead, go into Add/Remove Programs (or its equivalent) and select "Change" for PHP. In the install program, (de)select the options you want. Previous Comments: ---- [2010-11-10 01:41:09] josh at endries dot org This buug entry is NOT bogus. I just installed PHP from the web site and get this same error. PDO PGSQL is *NOT* included. I will submit a new ticket to actually get this addressed properly. [2010-02-03 19:51:10] paj...@php.net PDO PGSQL is part of the core distribution since years. Latest PHP releases include the PGSQL library and extensions, use them instead of PECL, on windows or source releases. [2010-02-03 19:33:39] jb at gmx dot at I think the source of the problem is that PHP 5.3 is not compatible with windows xp. Try using linux instead. [2010-02-02 13:38:08] michaelstrasser at tele2 dot at Description: Hi, I am using Windows XP with PHP 5.3 and I can't install PDO_PGSQL. This is what Pecl tells me: C:\Dokumente und Einstellungen\Michael>pecl install pdo_pgsql downloading PDO_PGSQL-1.0.2.tgz ... Starting to download PDO_PGSQL-1.0.2.tgz (14,961 bytes) .done: 14,961 bytes downloading PDO-1.0.3.tgz ... Starting to download PDO-1.0.3.tgz (52,613 bytes) ...done: 52,613 bytes 12 source files, building ERROR: The DSP PDO.dsp does not exist. 7 source files, building ERROR: The DSP PDO_PGSQL.dsp does not exist. Unfortunately the PECL site, where I could get snapshots of the extensions, is down. So I have no clue where to get the extension from. -- Edit this bug report at http://bugs.php.net/bug.php?id=50912&edit=1
#44610 [Com]: inputbox bug
ID: 44610 Comment by: josh at brink dot com Reported By: ricardo dot jorge86 at gmail dot com Status: Open Bug Type: *General Issues Operating System: XP PHP Version: 5.2CVS-2008-04-02 (CVS) New Comment: You put: ); ?> I think you are trying to do this: ); ?> Use of double quotes breaks apart the string. Previous Comments: [2008-04-02 13:44:16] ricardo dot jorge86 at gmail dot com Description: text including spaces placed in an input text control in HTML show the whole text. text including spaces placed in an input text control in PHP does not show the whole text, only the first word up to the first space is displayed. The same happens with variables from a BD. Reproduce code: --- ); ?> Expected result: inside the text box: any text Actual result: -- inside the text box: any -- Edit this bug report at http://bugs.php.net/?id=44610&edit=1
#39457 [Asn]: Multiple invoked OO connections never close
ID: 39457
User updated by: josh at mykoala dot com
Reported By: josh at mykoala dot com
Status: Assigned
Bug Type: MySQLi related
Operating System: OS X 10.4.8
PHP Version: 5.2.0
Assigned To: georg
New Comment:
About to celebrate the two-year anniversary of this one, woo! =)
Previous Comments:
[2007-06-28 20:14:39] [EMAIL PROTECTED]
Georg, reassign to someone else if this is not for you. :)
[2007-05-08 21:36:09] bugs dot php at david-salisbury dot co dot uk
I've experienced this behaviour on the latest PHP5 CVS (built May 8
2007 22:31:22) running in Apache 2.0.59 as mod_php5.
Further reproduce code if necessary:
init();
$m->real_connect('localhost', 'root', 'pass', 'dbname');
$m->real_connect('localhost', 'root', 'pass', 'dbname');
$m->real_connect('localhost', 'root', 'pass', 'dbname');
?>
[2006-11-10 12:00:27] josh at mykoala dot com
Description:
After invoking multiple identical connect() calls to a MySQLi
object (after mysqli_init), only one is closed via close() or
script termination.
Reproduce code:
---
# only when invoked through apache
$db = mysqli_init();
$db->connect(null, 'root');
$db->connect(null, 'root');
$db->close();
Expected result:
Just like when using procedural MySQLi functions (or via
mysql_* funcs), multiple connect() calls will not result in
rogue db connections.
Actual result:
--
Checking the MySQL process list after each execution shows a
rogue connection, which goes on until you reach max
connections.
This only happens when using OO style.
--
Edit this bug report at http://bugs.php.net/?id=39457&edit=1
#39321 [NEW]: $_FILES empty with enctype=multipart/form-data
From: josh at pixael dot com Operating system: linux PHP version: 4.4.4 PHP Bug Type: Variables related Bug description: $_FILES empty with enctype=multipart/form-data Description: i'm trying to upload a file via ssl in a form with method post and enctype=multipart/form-data if i upload a gif or jpg is all right if i upload a txt or a pdf or other with INTERNET EXPLORER $_FILES and $_POST is empty with firefox i've no problem php version 4.3.9 this is the url of the test https://www.service-store.com/tst.php Reproduce code: --- File Upload Test '; print_r($_POST); echo'Print $_FILES'; print_r($_FILES); ?> Send this file: -- Edit bug report at http://bugs.php.net/?id=39321&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39321&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39321&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39321&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39321&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39321&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39321&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39321&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39321&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39321&r=support Expected behavior:http://bugs.php.net/fix.php?id=39321&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39321&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39321&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39321&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39321&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39321&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39321&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39321&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39321&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39321&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39321&r=mysqlcfg
#39457 [NEW]: Multiple invoked OO connections never close
From: josh at mykoala dot com Operating system: OS X 10.4.8 PHP version: 5.2.0 PHP Bug Type: MySQLi related Bug description: Multiple invoked OO connections never close Description: After invoking multiple identical connect() calls to a MySQLi object (after mysqli_init), only one is closed via close() or script termination. Reproduce code: --- # only when invoked through apache $db = mysqli_init(); $db->connect(null, 'root'); $db->connect(null, 'root'); $db->close(); Expected result: Just like when using procedural MySQLi functions (or via mysql_* funcs), multiple connect() calls will not result in rogue db connections. Actual result: -- Checking the MySQL process list after each execution shows a rogue connection, which goes on until you reach max connections. This only happens when using OO style. -- Edit bug report at http://bugs.php.net/?id=39457&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39457&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39457&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39457&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39457&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39457&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39457&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39457&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39457&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39457&r=support Expected behavior:http://bugs.php.net/fix.php?id=39457&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39457&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39457&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39457&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39457&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39457&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39457&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39457&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39457&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39457&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39457&r=mysqlcfg
Bug #51404 [Com]: is_dir() returns false on cifs mounted share
Edit report at http://bugs.php.net/bug.php?id=51404&edit=1
ID: 51404
Comment by: josh at 6bit dot com
Reported by:neversaynever at tut dot by
Summary:is_dir() returns false on cifs mounted share
Status: Bogus
Type: Bug
Package:Directory function related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Just spent 5 hours trying to figure out an issue that was caused by this
bugger...
If PERL handles this case properly then there must be a small issue with
PHP's
implementation. I'm happy to attempt to provide a patch if someone can
point me in
the proper direction.
Previous Comments:
[2010-06-09 20:49:11] digitalaudiorock at gmail dot com
I just found a blog post (which I had to dredge out of the google cache)
where someone figured this out. The CIFS mount is now apparently using
the serverino option by default. In the case of Windows shares this
appears to be resulting in huge inode numbers which are causing is_dir()
to report false. Using the noserverino option prevents this. Scary
stuff.
[2010-06-09 20:06:02] digitalaudiorock at gmail dot com
I have to agree with the original poster. Running php 5.2.13 Under
Gentoo I have problems with is_dir() on CIFS shares with 2.6.31 and
2.6.32. On a machine I have running 2.6.30 I don't see the issue.
Here's a CIFS mounted directory that reports is_dir() as false even
though chdir() reports true:
php -r 'var_dump(is_dir("/home/tom/mount/sql"));'
bool(false)
php -r 'var_dump(chdir("/home/tom/mount/sql"));'
bool(true)
Here's the equivalent in perl that reports true:
perl -e '(-d "/home/tom/mount/sql") && print "OK\n"'
OK
ls -ald /home/tom/mount/sql
drwxr-xr-x 1 tom tom 0 Apr 28 2008 /home/tom/mount/sql
That's a windows share mounted as administrator of the windows machine.
While this may be caused somehow by CIFS changes in the kernel, there
truely is something ugly going on here and it's caused me some serious
problems.
Tom
[2010-06-08 14:33:22] tony2...@php.net
I'm sure PHP doesn't affect any of system functions, including stat().
You get what your stat() returns -> not PHP problem.
[2010-03-26 20:34:07] neversaynever at tut dot by
Description:
I upgraded my kernel to 2.6.31 (stable) and has php-5.2.12 (stable),
but
php function is_dir() returns false for folder on my cifs mounted
share.
strace php -r 'var_dump(is_dir("/path_to_mounted_folder/"));'
...
stat64("/path_to_mounted_folder/", {st_mode=S_IFDIR|0755, st_size=32768,
...}) = 0
gettimeofday({1269602972, 30466}, NULL) = 0
write(1, "bool(false)\n", 12bool(false)
) = 12
...
Test script:
---
php -r 'var_dump(is_dir("/path_to_mounted_folder/"));'
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51404&edit=1
[PHP-BUG] Bug #55172 [NEW]: Compile fails on sprintf.lo
From: Operating system: MacOS 10.7 PHP version: 5.3.6 Package: Compile Failure Bug Type: Bug Bug description:Compile fails on sprintf.lo Description: When downloading the source tarball for 5.3.6, a vanilla ./configure followed by a make fails. gcc info: i686-apple-darwin11-llvm-gcc-4.2 Expected result: No error Actual result: -- /Users/josh/php-5.3.6/main/spprintf.c:186: error: static declaration of âstrnlenâ follows non-static declaration /usr/include/string.h:143: error: previous declaration of âstrnlenâ was here make: *** [main/spprintf.lo] Error 1 -- Edit bug report at https://bugs.php.net/bug.php?id=55172&edit=1 -- Try a snapshot (PHP 5.2): https://bugs.php.net/fix.php?id=55172&r=trysnapshot52 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55172&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55172&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55172&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55172&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55172&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55172&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55172&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55172&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55172&r=support Expected behavior: https://bugs.php.net/fix.php?id=55172&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55172&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55172&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55172&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55172&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55172&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55172&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55172&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55172&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55172&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55172&r=mysqlcfg Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55172&r=trysnapshot54
Bug #55172 [Opn]: Compile fails on sprintf.lo
Edit report at https://bugs.php.net/bug.php?id=55172&edit=1
ID: 55172
User updated by:josh at joshbutts dot com
Reported by:josh at joshbutts dot com
Summary:Compile fails on sprintf.lo
Status: Open
Type: Bug
Package:Compile Failure
Operating System: MacOS 10.7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Wonder if this might be a problem with detecting the presence of strnlen().
Commenting this in main/sprintf.c fixes the problem:
#if !HAVE_STRNLEN
static size_t strnlen(const char *s, size_t maxlen) {
char *r = memchr(s, '\0', maxlen);
return r ? r-s : maxlen;
}
#endif
Previous Comments:
[2011-07-10 21:16:13] josh at joshbutts dot com
Description:
When downloading the source tarball for 5.3.6, a vanilla ./configure followed
by a make fails.
gcc info:
i686-apple-darwin11-llvm-gcc-4.2
Expected result:
No error
Actual result:
--
/Users/josh/php-5.3.6/main/spprintf.c:186: error: static declaration of
âstrnlenâ follows non-static declaration
/usr/include/string.h:143: error: previous declaration of âstrnlenâ was here
make: *** [main/spprintf.lo] Error 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=55172&edit=1
Bug #53742 [Com]: Late static binding does not work via reflection
Edit report at https://bugs.php.net/bug.php?id=53742&edit=1
ID: 53742
Comment by: josh at joshbutts dot com
Reported by:blue-tidus159 at hotmail dot com
Summary:Late static binding does not work via reflection
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7 x64
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Still exists in PHP 5.3.5. Reproducible with the script above.
Previous Comments:
[2011-05-12 20:06:23] phdaemon at gmail dot com
I experienced this bug when building a new automation framework using PHPUnit +
selenium.
IT seems that PHPUnit uses reflection to instantiate a static function called
suite which handles an array of browsers and duplicating a testcase to run in
each one.
I was on the latest ubuntu package: PHP 5.3.3-1ubuntu9.5 with Suhosin-Patch
(cli) (built: May 3 2011 00:49:55)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I got around it by switching the reflection to call_user_func but this should
probably be fixed as PHPUnit is very popular.
[2011-01-13 21:22:52] blue-tidus159 at hotmail dot com
Description:
When a static method is called through reflection, late static binding does not
work. Probably because the getMethod() returns the method associated to the
parent class.
Test script:
---
class A{
public static function call(){
static::callLate();
}
public static abstract function callLate();
}
class B{
public static function callLate(){
echo 'Late static binding';
}
}
B::call();
$class = new ReflectionClass('B');
$class->getMethod('call')->invoke(null);
Expected result:
Late static binding
Late static binding
Actual result:
--
Late static binding
Cannot call abstract method B::callLate()
--
Edit this bug report at https://bugs.php.net/bug.php?id=53742&edit=1
[PHP-BUG] Bug #63894 [NEW]: incorrect CURLINFO_HEADER_SIZE for proxied connections
From: josh at trash-mail dot com Operating system: PHP version: 5.4.10 Package: cURL related Bug Type: Bug Bug description:incorrect CURLINFO_HEADER_SIZE for proxied connections Description: When using CURLOPT_PROXY to connect to an HTTPS resource via an HTTP debugging proxy (like charles) CURLINFO_HEADER_SIZE incorrectly reports the header size without any headers that the proxy might have added. Example #1 (without proxy) reports CURLINFO_HEADER_SIZE 198 (correct): ## HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Example #2 (via proxy) reports CURLINFO_HEADER_SIZE 198 (wrong): ## HTTP/1.0 200 Connection established HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Expected result: CURLINFO_HEADER_SIZE should always return the correct size - also when CURLOPT_PROXY is used with an HTTP proxy to connect an HTTPS resource. Actual result: -- CURLINFO_HEADER_SIZE returns the wrong size (without counting the additional headers from the proxy). -- Edit bug report at https://bugs.php.net/bug.php?id=63894&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63894&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63894&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63894&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63894&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63894&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63894&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63894&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63894&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63894&r=support Expected behavior: https://bugs.php.net/fix.php?id=63894&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63894&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63894&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63894&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63894&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63894&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63894&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63894&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63894&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63894&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63894&r=mysqlcfg
#27642 [NEW]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
From: josh at trutwins dot homeip dot net Operating system: Linux SuSE 8.1 PHP version: 5.0.0RC1 PHP Bug Type: Compile Failure Bug description: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang Description: Attempting to compile PHP-5.0.0RC1 with MySQL 5.0.0 alpha built from source using --with-mysqli Here is the error: cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In function `stmt_affected_rows_read': /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' make: *** [ext/mysqli/mysqli_prop.lo] Error 1 Here is the configure script: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs \ \ --enable-exif \ --enable-ftp \ --enable-sockets \ --with-mcrypt \ --with-mhash \ --with-openssl \ --with-iconv \ --with-ncurses \ --with-readline \ --with-curl \ \ --with-bz2 \ --with-zip \ --with-zlib \ \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-mysql-sock=/usr/local/mysql/mysql.sock \ \ --with-pgsql=/usr/local/pgsql \ \ --with-oci8 \ \ --with-sqlite \ \ --with-gd \ --with-ttf \ --with-freetype \ --with-freetype-dir=/usr/X11/lib \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr \ \ --enable-xml \ --enable-wddx \ --with-xsl \ --with-expat-dir=/usr \ --with-libxml-dir=/usr/local \ --with-xmlrpc \ --with-dom \ --with-qtdom \ \ --with-java=/usr/local/java/ \ | tee config.out System is SuSE 8.1 with gcc 3.2 -- Edit bug report at http://bugs.php.net/?id=27642&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27642&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27642&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27642&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27642&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27642&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27642&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27642&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27642&r=support Expected behavior: http://bugs.php.net/fix.php?id=27642&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27642&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27642&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27642&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27642&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27642&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27642&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27642&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27642&r=float
#27642 [Opn]: mysqli_prop.c: In function `stmt_affected_rows_read'
ID: 27642 User updated by: josh at trutwins dot homeip dot net -Summary: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang Reported By: josh at trutwins dot homeip dot net Status: Open Bug Type: Compile Failure Operating System: Linux SuSE 8.1 PHP Version: 5.0.0RC1 New Comment: Oops, bad subject. Previous Comments: [2004-03-18 19:15:26] josh at trutwins dot homeip dot net Description: Attempting to compile PHP-5.0.0RC1 with MySQL 5.0.0 alpha built from source using --with-mysqli Here is the error: cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In function `stmt_affected_rows_read': /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' make: *** [ext/mysqli/mysqli_prop.lo] Error 1 Here is the configure script: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs \ \ --enable-exif \ --enable-ftp \ --enable-sockets \ --with-mcrypt \ --with-mhash \ --with-openssl \ --with-iconv \ --with-ncurses \ --with-readline \ --with-curl \ \ --with-bz2 \ --with-zip \ --with-zlib \ \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-mysql-sock=/usr/local/mysql/mysql.sock \ \ --with-pgsql=/usr/local/pgsql \ \ --with-oci8 \ \ --with-sqlite \ \ --with-gd \ --with-ttf \ --with-freetype \ --with-freetype-dir=/usr/X11/lib \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr \ \ --enable-xml \ --enable-wddx \ --with-xsl \ --with-expat-dir=/usr \ --with-libxml-dir=/usr/local \ --with-xmlrpc \ --with-dom \ --with-qtdom \ \ --with-java=/usr/local/java/ \ | tee config.out System is SuSE 8.1 with gcc 3.2 -- Edit this bug report at http://bugs.php.net/?id=27642&edit=1
#27642 [Bgs]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
ID: 27642 User updated by: josh at trutwins dot homeip dot net -Summary: mysqli_prop.c: In function `stmt_affected_rows_read' Reported By: josh at trutwins dot homeip dot net Status: Bogus Bug Type: Compile Failure Operating System: Linux SuSE 8.1 PHP Version: 5.0.0RC1 New Comment: Perhaps then the Changelog / Release Notices should be updated: - A new MySQL extension named MySQLi for developers using MySQL 4.1 and later. Additionally to a functional interface this new extension also includes an object-oriented interfaced and support for many of MySQL's new features such as prepared statements. "MySQL 4.1 and later" implies MySQL 5.0. Josh Previous Comments: [2004-03-19 03:14:30] spam at 8304 dot ch same problem under suse 9.0. 5.0.0b4 compiled perfectely, but with the same config.nice build of 5.0.0rc1 fails: #! /bin/sh # # Created by configure './configure' \ '--prefix=/usr/local/php5' \ '--with-apxs2=/usr/local/apache2/bin/apxs' \ '--with-iconv' \ '--enable-mbstring' \ '--enable-track-vars' \ '--enable-safe-mode' \ '--with-gd' \ '--with-curl' \ '--with-ttf' \ '--with-mysql=/usr/local/mysql500' \ '--with-mysqli=/usr/local/mysql500/bin/mysql_config' \ '--with-xml' \ '--enable-memory-limit' \ '--with-png-dir=/usr/lib' \ '--with-jpeg-dir=/usr/lib' \ '--with-freetype-dir=/usr/lib' \ '--with-zlib' \ '--enable-ftp' \ '--with-openssl' \ '--with-ldap' \ '--enable-mbstring' \ '--with-mssql=/usr/local/freetds' \ "$@" /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In function `stmt_affected_rows_read': /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error: structure has no member named `affected_rows' /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error: structure has no member named `affected_rows' /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error: structure has no member named `affected_rows' make: *** [ext/mysqli/mysqli_prop.lo] Error 1 [2004-03-19 01:16:37] [EMAIL PROTECTED] MySQL 5.0 is a preview version for SP's. Fixes and changes in 4.1 are currently not merged in 5.0 tree, this will probably happen when 4.1.3-beta will come out. [2004-03-18 19:23:43] josh at trutwins dot homeip dot net Oops, bad subject. [2004-03-18 19:15:26] josh at trutwins dot homeip dot net Description: Attempting to compile PHP-5.0.0RC1 with MySQL 5.0.0 alpha built from source using --with-mysqli Here is the error: cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In function `stmt_affected_rows_read': /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' make: *** [ext/mysqli/mysqli_prop.lo] Error 1 Here is the configure script: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs \ \ --enable-exif \ --enable-ftp \ --enable-sockets \ --with-mcrypt \ --with-mhash \ --with-openssl \ --with-iconv \ --with-ncurses \ --with-readline \ --with-curl \ \ --with-bz2 \ --with-zip \ --with-zlib \ \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-mysql-sock=/usr/local/mysql/mysql.sock \ \ --with-pgsql=/usr/local/pgsql \ \ --with-oci8 \ \ --with-sqlite \ \ --with-gd \ --with-ttf \ --with-freetype \ --with-freetype-dir=/usr/X11/lib \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr \ \ --enable-xml \ --enable-wddx \ --with-xsl \ --with-expat-dir=/usr \ --with-libxml-dir=/usr/local \ --with-xmlrpc \ --with-dom \ --with-qtdom \ \ --with-java=/usr/local/java/ \ | tee config.out System is SuSE 8.1 with gcc 3.2 -- Edit this bug report at http://bugs.php.net/?id=27642&edit=1
#27528 [Com]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
ID: 27528 Comment by: josh at trutwins dot homeip dot net Reported By: josh at netbits dot us Status: No Feedback Bug Type: Apache2 related Operating System: Linux SuSE 8.1 PHP Version: 5.0.0b4 (beta4) New Comment: Also, noticed the following in php error log: [23-Mar-2004 12:39:03] PHP Warning: PHP Startup: [EMAIL PROTECTED]@: Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=0 PHPcompiled with module API=20040316, debug=0, thread-safety=0 These options need to match in Unknown on line 0 This was tried with the following configure options. ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs Previous Comments: [2004-03-15 08:38:03] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2004-03-09 18:29:57] [EMAIL PROTECTED] Please isolate the problem to a particular module (by adding 1 module at a time to your configure). [2004-03-09 11:59:36] josh at netbits dot us Forgot, I also tried my original configure commands with CVS snapshot from yesterday afternoon - same results. [2004-03-09 11:58:15] josh at netbits dot us # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Using the php-5.0.0b4 release with these options works fine. Of course, it's not very useful. :) Also verified that httpd.conf did not contain additional load_module calls. I do not install any disto software for php/apache/mysql/etc and control all of this by building from source. Josh [2004-03-09 08:43:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip And try this for PHP: # ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs # make && make install # /usr/local/apache/bin/apachectl stop # /usr/local/apache/bin/apachectl start Also, make sure you're NOT loading any other PHP versions the same time in your apache httpd.conf (some distros come with preinstalled PHP, so..) 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/27528 -- Edit this bug report at http://bugs.php.net/?id=27528&edit=1
#27528 [Com]: Configuring php 5.0.0b4 from source with options below causes Apache2 to hang
ID: 27528 Comment by: josh at trutwins dot homeip dot net Reported By: josh at netbits dot us Status: Open Bug Type: Apache2 related Operating System: Linux SuSE 8.1 PHP Version: 5.0.0RC1 New Comment: I was able to fix this issue by re-creating the php.ini file. The following is a diff of my 4.3.4 php.ini and my current 5.0.0rc1 php.ini (any commented lines are ignored): diff /etc/httpd/php.ini.4.3.4 /etc/httpd/php.ini.5.0.0rc1 83c83,86 < ; Allow the tags are recognized. --- > ; Enable compatibility mode with Zend Engine 1 (PHP 4.x) > zend.ze1_compatibility_mode = Off > > ; Allow the tags are recognized. 115c118 < ; Using this ini directive may cause problems unless you know what script --- > ; Using this ini directive may cause problems unless you know what script 118c121 < ; and you cannot use both "ob_gzhandler" and "zlib.output_compression". --- > ; and you cannot use both "ob_gzhandler" and "zlib.output_compression". 124,127c127,130 < ; Note: Resulting chunk size may vary due to nature of compression. PHP < ; outputs chunks that are few handreds bytes each as a result of compression. < ; If you want larger chunk size for better performence, enable output_buffering < ; also. --- > ; Note: Resulting chunk size may vary due to nature of compression. PHP > ; outputs chunks that are few handreds bytes each as a result of compression. > ; If you want larger chunk size for better performence, enable output_buffering > ; also. 149c152 < ; So only set this entry, if you really want to implement such a --- > ; So only set this entry, if you really want to implement such a 183c186 < safe_mode_include_dir = ".:/usr/local/php:/usr/local/lib/php" --- > safe_mode_include_dir = 187c190 < safe_mode_exec_dir = "/usr/local/php/bin" --- > safe_mode_exec_dir = 202c205 < safe_mode_protected_env_vars = LD_LIBRARY_PATH, PATH --- > safe_mode_protected_env_vars = LD_LIBRARY_PATH 263a267,269 > ; E_STRICT - run-time notices, enable to have PHP suggest changes > ; to your code which will ensure the best interoperability > ; and forward compatability of your code 274a281,284 > ; - Show all errors, except for notices and coding standards warnings > ; > ;error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT > ; 312c322 < ; Ignore source of message when ignoring repeated messages. When this setting --- > ; Ignore source of message when ignoring repeated messages. When this setting 318c328 < ; stdout or in the log). This has only effect in a debug compile, and if --- > ; stdout or in the log). This has only effect in a debug compile, and if 325a336 > ; Note: Never use this feature for production boxes. 328c339 < ; If html_errors is set On PHP produces clickable error messages that direct --- > ; If html_errors is set On PHP produces clickable error messages that direct 330c341 < ; You can download a copy of the PHP manual from http://www.php.net/docs.php --- > ; You can download a copy of the PHP manual from http://www.php.net/docs.php 332c343 < ; leading '/'. You must also specify the file extension being used including --- > ; leading '/'. You must also specify the file extension being used including 333a345 > ; Note: Never use this feature for production boxes. 336c348 < --- > 357c369 < ; Default is "&". --- > ; Default is "&". 361c373 < ; Default is "&". --- > ; Default is "&". 381a394,398 > ; Whether or not to register the old-style input arrays, HTTP_GET_VARS > ; and friends. If you're not using them, it's recommended to turn them off, > ; for performance reasons. > register_long_arrays = Off > 390,392d406 < ; This directive is deprecated. Use variables_order instead. < gpc_order = "GPC" < 400c414 < magic_quotes_runtime = Off --- > magic_quotes_runtime = Off 417c431 < ; Always populate the $HTTP_RAW_POST_DATA variable. --- > ; Always populate the $HTTP_RAW_POST_DATA variable. 419a434 > 424c439 < ; UNIX: "/path1:/path2" --- > ; UNIX: "/path1:/path2" 455c470,474 < ; if cgi.force_redirect is turned on, and you are not running under Apache or Netscape --- > ; if cgi.nph is enabled it will force cgi to always sent Status: 200 with > ; every request. > ; cgi.nph = 1 > > ; if cgi.force_redirect is turned on, and you are not running under Apache or Netscape 461,468d479 < ; cgi.fix_path
Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735&edit=1
ID: 45735
Comment by: josh dot adell at gmail dot com
Reported by:johnston dot joshua at gmail dot com
Summary:preg_match fails with Segmentation Fault on
capturing subpattern
Status: Not a bug
Type: Bug
Package:PCRE related
Operating System: *
PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-06)
Block user comment: N
Private report: N
New Comment:
Just hit this bug today as well. It would be nice if PHP handled this more
gracefully by triggering an error or warning instead of segfaulting.
Previous Comments:
[2013-04-11 16:35:34] michael at writhem dot com
why is this status not a bug?
[2011-12-23 13:09:46] vojtech dot kurka at gmail dot com
We have hit this bug today on 5.3.8, just sending 70KB variable as an input to
preg_match_all().
Please fix this, it took us quite a lot of time to find the root cause. This
should never cause a segfault. If the preg_match_all() function would throw a
standard PHP error/warning, we would find the problem immeadiately. Debugging
such problems is just a waste of time, this bugreport is more than 3 years old.
[2011-12-15 14:42:35] josiecki at silvercube dot pl
Why is this bug status set to "Bogus"? Seems to be unsolved since over three
years, and I haven't found a single PHP installation that would not be
vulnerable to this, including quite new 5.3.8 installation...
[2008-08-07 13:44:55] johnston dot joshua at gmail dot com
Just for my own personal knowledge, is it the capturing pattern the part that
causes the recursion?
If I remove the () part of the pattern I can keep adding 0's to the below code
I can trigger a php memory error but no seg fault.
jjohnston:~$ php -r 'preg_match("/http:\/\/.+\.ru/i",
str_repeat("http://google.ru";, 200));
[2008-08-07 11:27:29] lbarn...@php.net
I seen that PCRE has a NO_RECURSE flag to avoid the recursion in
match() (described in pcre_exec.c).
Defining NO_RECURSE at compile time avoids this problem :)
diff -u -r1.38.2.3.2.10.2.3 config0.m4
--- ext/pcre/config0.m4 2 Jun 2008 14:12:20 -
1.38.2.3.2.10.2.3
+++ ext/pcre/config0.m4 7 Aug 2008 11:25:39 -
@@ -59,7 +59,7 @@
pcrelib/pcre_ord2utf8.c
pcrelib/pcre_refcount.c pcrelib/pcre_study.c \
pcrelib/pcre_tables.c
pcrelib/pcre_try_flipped.c pcrelib/pcre_valid_utf8.c \
pcrelib/pcre_version.c
pcrelib/pcre_xclass.c"
-PHP_NEW_EXTENSION(pcre, $pcrelib_sources php_pcre.c, no,,-
+PHP_NEW_EXTENSION(pcre, $pcrelib_sources php_pcre.c, no,,-
PHP_ADD_BUILD_DIR($ext_builddir/pcrelib)
PHP_INSTALL_HEADERS([ext/pcre], [php_pcre.h pcrelib/])
AC_DEFINE(HAVE_BUNDLED_PCRE, 1, [ ])
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
https://bugs.php.net/bug.php?id=45735
--
Edit this bug report at https://bugs.php.net/bug.php?id=45735&edit=1
Bug #50224 [Com]: json_encode() does not always encode a float as a float
Edit report at https://bugs.php.net/bug.php?id=50224&edit=1 ID: 50224 Comment by: josh dot adell at gmail dot com Reported by:christian dot lawrence at calorieking dot com Summary:json_encode() does not always encode a float as a float Status: Not a bug Type: Bug Package:JSON related PHP Version:5.2SVN-2009-11-19 (snap) Block user comment: N Private report: N New Comment: This is still an issue, specifically when JSON encoding for talking to APIs that don't allow mixed type arrays. For instance, json_encode(array(1.2, 2.3)) properly encodes to "[1.2, 2.3]" But, json_encode(array(1.0, 2.3)) encodes to "[1, 2.3]" which fails if the receiving end does not allow mixed-type arrays. Any chance on this ever being fixed? PHP Version: 5.3.10 Previous Comments: [2009-11-20 10:39:53] christian dot lawrence at calorieking dot com And there lines the problem - there is no way to express the fractional part if json_encode() does not even deal with it in the first place. An integer and an integer represented as a floating point number are not the same thing because they have different types, as follows: Numerically they have the same value, but we all know this to be true: There is always a fractional part of any integer when it is represented as a floating point number. It is implied and can, simply, be expressed by appending a ".0" to the integer part. There is nothing in the JSON encoding rules on http://www.json.org/ which disallows this (see "int frac" form for specifics). Decoding a valid and legitimate encoding of an integer when it is represented as a floating point number gives the correct PHP floating point type: Decoding an integer-encoded stream also gives the correct PHP integer type: I fail to see how my bug report is bogus when json_encode() is unable to produce a perfectly valid and legitimate encoding yet json_decode() is capable of doing the right thing. Surely, the json_encode() implementation must be identifying the data type being encoded, presumably it is using equivalents for is_object() and is_array(). Why not use equivalents for is_int() or is_float() as well? A reliable data interchange format should not purport to do any type-casting from the primitive types it was provided for encoding. ie: If you encode a float then you should expect to decode a float. As far as I am concerned json_encode() is un-reliable and fails to encode my float, which I have confirmed in my results. I humbly ask that you reconsider your position. [2009-11-19 15:12:56] j...@php.net Yes, IF you were passing fractional part. But you're not. See the output of var_dump($f) in your results.. [2009-11-19 09:14:05] christian dot lawrence at calorieking dot com Take a look at the format for "number" at http://www.json.org/ and observe the form for a "int frac". This clearly indicates that there is support for representing a floating point number, even integer floats. The json_encode() function clearly supports encoding of floating point numbers. json_decode() is capable of deserialising "12.0" as a integer floating point number. If you encode a floating point number, then one should expect to decode a floating point number. If json_encode()/json_decode() is to be used as a serious and reliable data exchange format, then there should be no loss or conversion of primitive type information. Please re-consider. [2009-11-19 08:51:56] j...@php.net There's is just "number" type in JSON for numbers. And as such, this is working just like it should and PHP tries it's best at guessing what type the numbers might be. [2009-11-19 05:45:10] christian dot lawrence at calorieking dot com Description: json_encode()-ing an integer when it is represented as floating point number results in a change of type when json_decode() decodes the output. Examples of such floating point numbers are: -123.0, -1.0, 0.0, 1.0, 123.0 Reproduce code: --- Expected result: float(12.3) string(4) "12.3" float(12.3) int(12) string(2) "12" int(12) float(12) string(4) "12.0" float(12) float(0) string(3) "0.0" float(0) Actual result: -- float(12.3) string(4) "12.3" float(12.3) int(12) string(2) "12" int(12) float(12) string(2) "12" int(12) float(0) string(1) "0" int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=50224&edit=1
#50225 [NEW]: count() on undefined var does not trigger NOTICE
From: josh dot ribakoff at gmail dot com Operating system: Windows Vista PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: count() on undefined var does not trigger NOTICE Description: Example A "compiles" and B does not (E_NOTICE). Invoking an array index on NULL *probably* warrants my attention more than doing so on an array. It has cost me countless hours, for one. Reproduce code: --- // A $foo = null; count( $foo['bar'] ); // B $foo = array(); count( $foo['bar'] ); Expected result: 2 E_NOTICE errors Actual result: -- 1 E_NOTICE error -- Edit bug report at http://bugs.php.net/?id=50225&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50225&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50225&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50225&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50225&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50225&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50225&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50225&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50225&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50225&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50225&r=support Expected behavior: http://bugs.php.net/fix.php?id=50225&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50225&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50225&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50225&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50225&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50225&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50225&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50225&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50225&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50225&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50225&r=mysqlcfg
#50225 [Bgs]: count() on undefined var does not trigger NOTICE
ID: 50225
User updated by: josh dot ribakoff at gmail dot com
Reported By: josh dot ribakoff at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
I disagree with your explanation because $foo['bar'] is never created
as $foo still equals NULL according to my debugger.
And to quote the manual:
"Note: Attempting to access an array key which has not been defined is
the same as accessing any other undefined variable: an E_NOTICE-level
error message will be issued, and the result will be NULL. "
I did RTFM, and it never said anything about trying to access a
variable causing it to be created. The explanation left in the related
bug you referenced is probably more accurate
"Note: Accessing variables of other types using [] or {} silently
returns NULL. "
Even if this is "by design" I still think it should generate a NOTICE,
where could I read about the design decisions of why it was done the way
it was? And would it be appropriate to re-categorize this as a feature
suggestion or do you guys not want to hear about it?
Previous Comments:
[2009-11-19 08:32:32] j...@php.net
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
RTFM:
http://php.net/count
"There is one exception, if var is NULL, 0 will be returned."
http://php.net/array
"Converting NULL to an array results in an empty array."
See also bug #44821
[2009-11-19 07:54:09] josh dot ribakoff at gmail dot com
Description:
Example A "compiles" and B does not (E_NOTICE).
Invoking an array index on NULL *probably* warrants my attention more
than doing so on an array.
It has cost me countless hours, for one.
Reproduce code:
---
// A
$foo = null;
count( $foo['bar'] );
// B
$foo = array();
count( $foo['bar'] );
Expected result:
2 E_NOTICE errors
Actual result:
--
1 E_NOTICE error
--
Edit this bug report at http://bugs.php.net/?id=50225&edit=1
#47522 [Com]: __toString() segfault
ID: 47522
Comment by: josh dot butts at vertive dot com
Reported By: ms419 at freezone dot co dot uk
Status: Open
Bug Type: Reproducible crash
Operating System: Debian
PHP Version: 5.2CVS-2009-02-27 (snap)
New Comment:
We have also tracked down a segfault which appears to be directly
related to this.
getElement('query'))?>
where $form is a Zend_Form object from Zend Framework. Not able to
reproduce it out of context but within the context of the site happens
almost 100% of the time. Removing html_entity_decode() fixes the
segfault, as does casting (string) on the $form, or calling
$form->render(). The implicit call to __toString() appears to be the
root cause of this problem.
Previous Comments:
[2009-03-02 19:23:02] ms419 at freezone dot co dot uk
Unfortunately I have been unable to reproduce this segfault in a short
script - it seems whenever I try to cut something out of the larger
project where it occurs, the segfault disappears.
Casting the object to a string in a parent function does not produce a
segfault, while calling a function and casting in the called function
does. Even passing the object as the first as opposed to fourth argument
of the function causes the segfault to disappear.
The segfault occurs at line eight of this file:
http://code.google.com/p/qubit-toolkit/source/browse/trunk/qubit/apps/qubit/modules/repository/templates/showIsdiahSuccess.php#8
Since r2041, a workaround has been committed to the render_title()
function: http://code.google.com/p/qubit-toolkit/source/detail?r=2041
Removing that workaround causes the segfault to reappear.
I am eager to help any way I can - but I have had no luck reproducing
this segfault in a short script...
[2009-02-27 19:28:24] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-02-27 18:52:36] ms419 at freezone dot co dot uk
Description:
http://cgi.sfu.ca/~jdbates/tmp/php/200902270/core
I am experiencing a reproducible segfault. I experience it with PHP
5.2.4 and 5.2.6.
The segfault occurs at this expression: strlen($repository) where
$repository is an object with a __toString() method.
By substituting this expression, the segfault does not occur:
strlen($repository->__toString())
To try to debug this segfault, I compiled a recent 5.2 snapshot with
--enable-debug. It produced the above linked core file, which I opened
with gdb to print a backtrace:
http://cgi.sfu.ca/~jdbates/tmp/php/200902270/screenlog
I am not sure what should be my next steps to help fix this segfault?
--
Edit this bug report at http://bugs.php.net/?id=47522&edit=1
[PHP-BUG] Bug #53135 [NEW]: I have PHP >5 and have a call-time pass-by-reference problem
From:
Operating system: CentOS 5.5
PHP version: Irrelevant
Package: Sockets related
Bug Type: Bug
Bug description:I have PHP >5 and have a call-time pass-by-reference problem
Description:
I'm trying to use fsocketopen() to test a server connection- to see if it's
online or offline.
Even the manual says I can call it like this:
$connection = fsockopen("www.example.com", 80, $errno, $errstr, 30);
However, I get this warning message when doing so:
PHP Warning: Call-time pass-by-reference has been deprecated - argument
passed by value; If you would like to pass it by reference, modify the
declaration of fsockopen(). If you would like to enable call-time
pass-by-reference, you can set allow_call_time_pass_reference to true in
your INI file. However, future versions may not support this any longer.
Is there another way to declare fsocketopen()??? I see nothing about this!!
Test script:
---
Expected result:
Not expecting any warning!!
Actual result:
--
Where does this warning come from? I've called fsocketopen() like this for
years!!
--
Edit bug report at http://bugs.php.net/bug.php?id=53135&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53135&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53135&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53135&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53135&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53135&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53135&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53135&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53135&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53135&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53135&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53135&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53135&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53135&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53135&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53135&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53135&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53135&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53135&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53135&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53135&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53135&r=mysqlcfg
Bug #53135 [Com]: I have PHP >5 and have a call-time pass-by-reference problem
Edit report at http://bugs.php.net/bug.php?id=53135&edit=1
ID: 53135
Comment by: josh dot richard at gmail dot com
Reported by:josh dot richard at gmail dot com
Summary:I have PHP >5 and have a call-time pass-by-reference
problem
Status: Bogus
Type: Bug
Package:Sockets related
Operating System: CentOS 5.5
PHP Version:Irrelevant
Block user comment: N
New Comment:
Sorry, I misread that page at first. Thanks!
Previous Comments:
[2010-10-22 10:32:43] ahar...@php.net
You shouldn't specify &$errno and &$errstr with the & operator;
simply providing $errno and $errstr will work fine.
Further explanation: http://php.net/language.references.pass
Not a bug; closing.
----
[2010-10-22 10:23:10] josh dot richard at gmail dot com
Description:
I'm trying to use fsocketopen() to test a server connection- to see if
it's online or offline.
Even the manual says I can call it like this:
$connection = fsockopen("www.example.com", 80, $errno, $errstr, 30);
However, I get this warning message when doing so:
PHP Warning: Call-time pass-by-reference has been deprecated - argument
passed by value; If you would like to pass it by reference, modify the
declaration of fsockopen(). If you would like to enable call-time
pass-by-reference, you can set allow_call_time_pass_reference to true in
your INI file. However, future versions may not support this any
longer.
Is there another way to declare fsocketopen()??? I see nothing about
this!!
Test script:
---
Expected result:
Not expecting any warning!!
Actual result:
--
Where does this warning come from? I've called fsocketopen() like this
for years!!
--
Edit this bug report at http://bugs.php.net/bug.php?id=53135&edit=1
#42713 [NEW]: Undocumented behavior when strftime() $format param is >= 1024 characters
From: josh dot helzer at gmail dot com
Operating system: Irrelevant
PHP version: 5.2.4
PHP Bug Type: Date/time related
Bug description: Undocumented behavior when strftime() $format param is >=
1024 characters
Description:
If strlen($format) >= 1024, then the output of strftime($format, $date) is
the empty string.
I'd at least like to see a note of this appear in strftime()'s
documentation.exactly
Reproduce code:
---
strftime(str_repeat('a', 1024), time())
Expected result:
str_repeat('a', 1024)
Actual result:
--
''
--
Edit bug report at http://bugs.php.net/?id=42713&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42713&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42713&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42713&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42713&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42713&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42713&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42713&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42713&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42713&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42713&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42713&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42713&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42713&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42713&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42713&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42713&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42713&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42713&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42713&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42713&r=mysqlcfg
#40832 [NEW]: Behavior of PI end in single-line comment
From: josh dot helzer at gmail dot com Operating system: Linux 2.4.26-gentoo-r7 PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: Behavior of PI end in single-line comment Description: When a processing instruction end (PIE), i.e., "?>", is encountered in a single-line comment, the PHP parser should handle it more intelligently, thus: If the PIE would, when outside single-line comment context (SLCC), not mark the end of the current PHP code block (e.g., if it occurred inside a string literal), it should not, when inside SLCC, mark the end of the code block. --- The above represents a compromise suggestion. I feel the semantics of comments ought to be the same as those in, e.g., C, Perl; i.e., comment text should be naively stripped from the input stream seen by the parser. -- Edit bug report at http://bugs.php.net/?id=40832&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40832&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40832&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40832&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40832&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40832&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40832&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40832&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40832&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40832&r=support Expected behavior:http://bugs.php.net/fix.php?id=40832&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40832&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40832&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40832&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40832&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40832&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40832&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40832&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40832&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40832&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40832&r=mysqlcfg
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: josh at spinningplanet dot co dot nz Reported By: golden at riscom dot com Status: No Feedback Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 Assigned To: sniper New Comment: Try disabling safe mode Previous Comments: [2007-02-03 16:51:38] earnie at users dot sourceforge dot net Just to note: This error happens if the functions identified in session_set_save_handler are not defined at the time of the call. [2006-12-09 20:02:53] thecancerus at gmail dot com we can pass session id to ensuser that session remains intact.. use SID it will help [2006-07-21 08:05:00] contact at far-php dot ro Hy i have this problem as well. PHP version 4.3.11 Script index.php: session_start(); ob_start(); /tmp -> /domanin_site/tmp/ [2006-06-27 06:28:57] hmahmoud1900 at gmail dot com still have same problem , user session empty and get out of the site. try all what the guys said , nothing happened [2006-03-28 13:45:31] stjernstrom at gmail dot com We have this problem to. Nothing helps :( 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
[PHP-BUG] Bug #54505 [NEW]: Date("Y") for Dec returns incorrectly
From:
Operating system: Windows 7
PHP version: 5.3.6
Package: Date/time related
Bug Type: Bug
Bug description:Date("Y") for Dec returns incorrectly
Description:
I am actually running PHP 5.3.5 on Apache 2.2 on Windows 7 as my
development machine.
php.net states:
W ISO-8601 week number of year, weeks starting on Monday (added in PHP
4.1.0)
I have a calender class that I created that lists the weeks of the year for
a given month. For certain years when January 1st is not on Sunday or
Monday the date function is returning that it is still on the first week of
the year where if the weeks start on Monday it should be returning the last
week of the previous year. This then offsets the rest of the year. I
noticed it when I had a Dec. with week 54.
Test script:
---
for ($i=2000; $i<2040; $i++){
// Week of the Year
$WoY = (int) date("W", mktime(0, 0, 0, 1, 1, $i));
// Day of Jan 1st
$DoM = date("l", mktime(0, 0, 0, 1, 1, $i));
// If the week is 1 then the day must be either Sunday or Monday;
otherwise we are still in the previous year
if ($WoY == 1 && !($DoM == "Monday" || $DoM == "Sunday"))
print "$DoM Jan 1, $i is on week $WoY\n\n";
}
Expected result:
Actual result:
--
Tuesday Jan 1, 2002 is on week 1
Wednesday Jan 1, 2003 is on week 1
Thursday Jan 1, 2004 is on week 1
Tuesday Jan 1, 2008 is on week 1
Thursday Jan 1, 2009 is on week 1
Tuesday Jan 1, 2013 is on week 1
Wednesday Jan 1, 2014 is on week 1
Thursday Jan 1, 2015 is on week 1
Tuesday Jan 1, 2019 is on week 1
Wednesday Jan 1, 2020 is on week 1
Wednesday Jan 1, 2025 is on week 1
Thursday Jan 1, 2026 is on week 1
Tuesday Jan 1, 2030 is on week 1
Wednesday Jan 1, 2031 is on week 1
Thursday Jan 1, 2032 is on week 1
Tuesday Jan 1, 2036 is on week 1
Thursday Jan 1, 2037 is on week 1
Wednesday Jan 1, 2039 is on week 1
--
Edit bug report at http://bugs.php.net/bug.php?id=54505&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54505&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54505&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54505&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54505&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54505&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54505&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54505&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54505&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54505&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54505&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54505&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54505&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54505&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54505&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54505&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54505&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54505&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54505&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54505&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54505&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54505&r=mysqlcfg
Bug #54505 [Opn]: Date("Y") for certain years returns incorrectly
Edit report at http://bugs.php.net/bug.php?id=54505&edit=1
ID: 54505
User updated by:josh dot reinert at gmail dot com
Reported by:josh dot reinert at gmail dot com
-Summary:Date("Y") for Dec returns incorrectly
+Summary:Date("Y") for certain years returns incorrectly
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Trying to modify the summary since it affects the year not just the
month
Previous Comments:
----
[2011-04-11 16:35:45] josh dot reinert at gmail dot com
Description:
I am actually running PHP 5.3.5 on Apache 2.2 on Windows 7 as my
development machine.
php.net states:
W ISO-8601 week number of year, weeks starting on Monday (added in PHP
4.1.0)
I have a calender class that I created that lists the weeks of the year
for a given month. For certain years when January 1st is not on Sunday
or Monday the date function is returning that it is still on the first
week of the year where if the weeks start on Monday it should be
returning the last week of the previous year. This then offsets the
rest of the year. I noticed it when I had a Dec. with week 54.
Test script:
---
for ($i=2000; $i<2040; $i++){
// Week of the Year
$WoY = (int) date("W", mktime(0, 0, 0, 1, 1, $i));
// Day of Jan 1st
$DoM = date("l", mktime(0, 0, 0, 1, 1, $i));
// If the week is 1 then the day must be either Sunday or Monday;
otherwise we are still in the previous year
if ($WoY == 1 && !($DoM == "Monday" || $DoM == "Sunday"))
print "$DoM Jan 1, $i is on week $WoY\n\n";
}
Expected result:
Actual result:
--
Tuesday Jan 1, 2002 is on week 1
Wednesday Jan 1, 2003 is on week 1
Thursday Jan 1, 2004 is on week 1
Tuesday Jan 1, 2008 is on week 1
Thursday Jan 1, 2009 is on week 1
Tuesday Jan 1, 2013 is on week 1
Wednesday Jan 1, 2014 is on week 1
Thursday Jan 1, 2015 is on week 1
Tuesday Jan 1, 2019 is on week 1
Wednesday Jan 1, 2020 is on week 1
Wednesday Jan 1, 2025 is on week 1
Thursday Jan 1, 2026 is on week 1
Tuesday Jan 1, 2030 is on week 1
Wednesday Jan 1, 2031 is on week 1
Thursday Jan 1, 2032 is on week 1
Tuesday Jan 1, 2036 is on week 1
Thursday Jan 1, 2037 is on week 1
Wednesday Jan 1, 2039 is on week 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=54505&edit=1
Bug #54505 [Bgs]: Date("Y") for certain years returns incorrectly
Edit report at http://bugs.php.net/bug.php?id=54505&edit=1
ID: 54505
User updated by:josh dot reinert at gmail dot com
Reported by:josh dot reinert at gmail dot com
Summary:Date("Y") for certain years returns incorrectly
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Oh wow, sorry Derick. I miss interpreted the "weeks start on Monday" to
include the first of the year. As for what I am trying to do, our
company uses the weeks of the year to calculate the "Month's End". Our
weeks actually start on Sunday's and according to one of our Accountants
the first Sunday of the year is week 1. I apologize for submitting a
bad report. Thank you for the information.
Previous Comments:
[2011-04-11 16:58:44] der...@php.net
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
Uh, what are you trying to do here? The year is the ISO-year, and the W
an ISO-week number. Please read up on how that works here:
http://en.wikipedia.org/wiki/ISO_year#Relation_with_the_Gregorian_calendar
----
[2011-04-11 16:39:32] josh dot reinert at gmail dot com
Trying to modify the summary since it affects the year not just the
month
----
[2011-04-11 16:35:45] josh dot reinert at gmail dot com
Description:
I am actually running PHP 5.3.5 on Apache 2.2 on Windows 7 as my
development machine.
php.net states:
W ISO-8601 week number of year, weeks starting on Monday (added in PHP
4.1.0)
I have a calender class that I created that lists the weeks of the year
for a given month. For certain years when January 1st is not on Sunday
or Monday the date function is returning that it is still on the first
week of the year where if the weeks start on Monday it should be
returning the last week of the previous year. This then offsets the
rest of the year. I noticed it when I had a Dec. with week 54.
Test script:
---
for ($i=2000; $i<2040; $i++){
// Week of the Year
$WoY = (int) date("W", mktime(0, 0, 0, 1, 1, $i));
// Day of Jan 1st
$DoM = date("l", mktime(0, 0, 0, 1, 1, $i));
// If the week is 1 then the day must be either Sunday or Monday;
otherwise we are still in the previous year
if ($WoY == 1 && !($DoM == "Monday" || $DoM == "Sunday"))
print "$DoM Jan 1, $i is on week $WoY\n\n";
}
Expected result:
Actual result:
--
Tuesday Jan 1, 2002 is on week 1
Wednesday Jan 1, 2003 is on week 1
Thursday Jan 1, 2004 is on week 1
Tuesday Jan 1, 2008 is on week 1
Thursday Jan 1, 2009 is on week 1
Tuesday Jan 1, 2013 is on week 1
Wednesday Jan 1, 2014 is on week 1
Thursday Jan 1, 2015 is on week 1
Tuesday Jan 1, 2019 is on week 1
Wednesday Jan 1, 2020 is on week 1
Wednesday Jan 1, 2025 is on week 1
Thursday Jan 1, 2026 is on week 1
Tuesday Jan 1, 2030 is on week 1
Wednesday Jan 1, 2031 is on week 1
Thursday Jan 1, 2032 is on week 1
Tuesday Jan 1, 2036 is on week 1
Thursday Jan 1, 2037 is on week 1
Wednesday Jan 1, 2039 is on week 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=54505&edit=1
#14599 [Com]: Script Output Stops
ID: 14599
Comment by: josh dot nospam at hostyour dot info dot nospam
Reported By: darren at coolpink dot net
Status: Closed
Bug Type: Reproducible crash
Operating System: SuSE Linux 6.4
PHP Version: 4.1.0
New Comment:
I've noticed the same problem, and reproduced it in my own. I have PHP
4.3.4 and Zend Optimizer 2.5.0 installed on RH7.3
If I have a function that has a do..while(); construction in it, inside
a block container { }, PHP will segfault on exiting the block container
UNLESS I have a statement in between the end of the while (); and the
closing brace of the block.
This snippet segfaults:
function announce()
{
global $totalRows_announce, $row_announce, $announce, $srs;
$ann = "";
if ($totalRows_announce > 0) {
do {
$author = mysql_result(mysql_query("SELECT nick FROM players
WHERE
id='".$row_announce['author']."'", $srs), 0, "nick") or
die(mysql_error());
$msg_body =
stripslashes(implode("",explode("\n",$row_announce['msg_body'])));
$ann .= textBlock(textBlock($row_announce['subject'], "",
"anntitle") . br() .
textBlock("Posted by:".$author." | On:
".$row_announce['posted_date'], "", "annhead") . br() .
textBlock($msg_body, "", "annbody"), "",
(($row_announce['urgent']
== 1) ? "redrow" : ((($ctr++) % 2) ? "lightrow" : "darkrow"))) . br();
} while ($row_announce = mysql_fetch_assoc($announce));
} else {
$ann = textBlock("No Announcements", "", "loginerr");
}
return $ann;
}
This one does not:
function announce()
{
global $totalRows_announce, $row_announce, $announce, $srs;
$ann = "";
if ($totalRows_announce > 0) {
do {
$author = mysql_result(mysql_query("SELECT nick FROM players
WHERE
id='".$row_announce['author']."'", $srs), 0, "nick") or
die(mysql_error());
$msg_body =
stripslashes(implode("",explode("\n",$row_announce['msg_body'])));
$ann .= textBlock(textBlock($row_announce['subject'], "",
"anntitle") . br() .
textBlock("Posted by:".$author." | On:
".$row_announce['posted_date'], "", "annhead") . br() .
textBlock($msg_body, "", "annbody"), "",
(($row_announce['urgent']
== 1) ? "redrow" : ((($ctr++) % 2) ? "lightrow" : "darkrow"))) . br();
} while ($row_announce = mysql_fetch_assoc($announce));
echo "";
} else {
$ann = textBlock("No Announcements", "", "loginerr");
}
return $ann;
}
Note that the only difference between the two is the echo ""; statement
immediately following the while(); clause.
This does NOT happen in "global" execution. A do..while() loop that
lives outside any function's scope works just fine; I have several
other do..while() constructs outside of functions that work with no
problems. The segfault seems to only happen when the do..while(); is
inside a function AND inside a block container (in this case, belonging
to an if statement).
Any ideas?
Previous Comments:
[2002-10-31 03:39:38] john at alamak dot com dot sg
I get this all the time when I include a recursive function call. I've
tried rewriting the function several ways and get intermitten
Segmentation faults.
I"ve tried just opening the fh and going down recursive directories
with this, got the seg faults often.This version
buffers the file names in an array, closes the directory handle then
processes the array, to count certain types of files in the directory
tree. Still segfaults often enough to make it unreliable. I turned on
the autoflush in php.ini and it dies in this routine.
FreeBSD 4.5-RELEASE
Apache/1.3.26 (Unix) PHP/4.2.2 mod_ssl/2.8.9 OpenSSL/0.9.6g
RegisterGlobals = On :)
function CountFiles($dir,$d) {
global $home;
global $prod_count;
$farray = array(); $d++;
if (is_dir("$home$dir")) {
print "\n";
if ($dfh = @opendir("$home$dir")) {
while (($fil = readdir($dfh)) !== false
Bug #46851 [Com]: Strict standards: Declaration of ... should be compatible with that of ...
Edit report at https://bugs.php.net/bug.php?id=46851&edit=1
ID: 46851
Comment by: josh dot x dot guthrie at gmail dot com
Reported by:oliver at teqneers dot de
Summary:Strict standards: Declaration of ... should be
compatible with that of ...
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: OpenSuSE 11.0
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
This is not a bug in PHP, this is a flaw in your understanding of PHP and how
it
handles method overloading. If your child class inherits from the parent class
and you override one of the parent class's methods, you must still pass it the
same number of parameters. Ex:
abstract class B extends A {
public static function foo($str){ echo $str; }
}
abstract class A {
public static function foo(){ echo 'bar'; }
}
What you will notice is that class A has a method "foo" which takes no
parameters. We then extend A with class B which overrides the method "foo" and
gives it a parameter "$str". This method overload is causing the strict error.
If you want a fix, make the parameter optional and it should remove the strict
warning. This fix has been tested with the __autoload function for class
loading.
Previous Comments:
[2010-11-09 02:49:37] gabriel dot delepine at gmail dot com
I have exactly the same problem.
Autoload() is called for the subclass before the class. A error E_STRICT is
throw.
I use PHP 5.3.2-1 on Ubuntu Serveur 10.04
It append for me when I use the design pattern sigleton and when I call the
function getInstance() of the subclass. This function have to return an
instance
of the subclass but the error E_STRICT is throw.
I check the change log of PHP 5.3.3-1 but I seen nothing about this.
[2010-07-14 21:46:58] demaio at vanylla dot it
I sthis a PHP bug then?
Is this bug going to be fixed?
[2010-07-11 16:45:07] col...@php.net
What change?
The error is in both cases here, only that in one case, it is not displayed
because at the time it is emitted, error_reporting does not contain E_STRICT
(.e. php.ini).
It's not about ensuring class loading order. It is simply that if you define
classes in a "wrong" order, or if you use autoload, classes loading will get
postponed at runtime, hence errors will be triggered at runtime i.e. after the
error_reporting call.
[2010-07-11 14:48:04] david at customcode dot co dot za
Surely this counts as a bug when you consider it in the context of applications
that make extensive use autoload. I realise I am a bit late to this party but
from what I can see the strict standard was changed in php 5.2.10 but I can't
seem to find any mention of this change in the changelog. This appears to be a
fairly major change potentially affecting alot of people's code. I would expect
at least some documentation of the rationale behind the change and at least
some guidelines. That being said, surely when it comes to ensuring that classes
are loaded/compiled in the correct order, classes that needed to be autoloaded
should be loaded first before the child class is compiled. Or am I missing
something?
[2010-06-30 09:48:04] col...@php.net
It is simply related to the fact that if the classes are in the right order,
they
get defined at compile time and hence that strict error happens at
compile-time,
which is before you actually set to display E_STRICT.
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
https://bugs.php.net/bug.php?id=46851
--
Edit this bug report at https://bugs.php.net/bug.php?id=46851&edit=1
