#38279 [NEW]: mktime dont work right on all 31 day of a month
From: support at ml-networld dot de
Operating system: Debian Sarge
PHP version: 4CVS-2006-08-01 (CVS)
PHP Bug Type: Date/time related
Bug description: mktime dont work right on all 31 day of a month
Description:
On the 31 Juli, Oktober, Dezember the code below say that the lastmonth is
the current month. But on the 31 August it say that the last month is jul.
this code is an example code from nuntius on the site
http://de2.php.net/manual/de/function.mktime.php
Reproduce code:
---
$dateMinusOneMonth = mktime(0, 0, 0, date("m")-1, date("d"), date("Y"));
$lastmonth = date("M", $dateMinusOneMonth);
echo $lastmonth;
Expected result:
on the 31 juli
jun
on the 31 oktober
sep
on the 31 dezember
nov
Actual result:
--
on the 31 juli
jul
on the 31 oktober
okt
on the 31 dezember
dez
--
Edit bug report at http://bugs.php.net/?id=38279&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38279&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38279&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38279&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38279&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38279&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38279&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38279&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38279&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38279&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38279&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38279&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38279&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38279&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38279&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38279&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38279&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38279&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38279&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38279&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38279&r=mysqlcfg
#38279 [Opn]: mktime dont work right on all 31 day of a month
ID: 38279
User updated by: support at ml-networld dot de
Reported By: support at ml-networld dot de
Status: Open
Bug Type: Date/time related
Operating System: Debian Sarge
-PHP Version: 4CVS-2006-08-01 (CVS)
+PHP Version: 5.1.4
New Comment:
sorry,
i put the wrong phpversion
Previous Comments:
[2006-08-01 07:09:09] support at ml-networld dot de
Description:
On the 31 Juli, Oktober, Dezember the code below say that the lastmonth
is the current month. But on the 31 August it say that the last month is
jul. this code is an example code from nuntius on the site
http://de2.php.net/manual/de/function.mktime.php
Reproduce code:
---
$dateMinusOneMonth = mktime(0, 0, 0, date("m")-1, date("d"),
date("Y"));
$lastmonth = date("M", $dateMinusOneMonth);
echo $lastmonth;
Expected result:
on the 31 juli
jun
on the 31 oktober
sep
on the 31 dezember
nov
Actual result:
--
on the 31 juli
jul
on the 31 oktober
okt
on the 31 dezember
dez
--
Edit this bug report at http://bugs.php.net/?id=38279&edit=1
#38278 [Opn->Fbk]: session_cache_expire()'s value does not match phpinfo's session.cache_expire
ID: 38278
Updated by: [EMAIL PROTECTED]
Reported By: winterain at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Windows
PHP Version: 4.4.2
New Comment:
Are you sure you changed correct php.ini and restarted the web server
after that?
Previous Comments:
[2006-08-01 03:25:44] winterain at gmail dot com
Description:
I have tried setting the session.cache_expire time to 5 mins with the
use of session_cache_expire(5) function... it does not work... the
session will still expire after 180mins which is the default value for
session.cache_expire.
Reproduce code:
---
session_cache_limiter('private');
session_cache_expire(5);
session_start();
phpinfo();
echo session_cache_expire();
Expected result:
after running the code, i'm expecting that phpinfo()'s
session.cache_expire's local value will be 5. And phpinfo()'s
session.cache_expire's local value should match the value returned by
session_cache_expire().
Actual result:
--
phpinfo's session.cache_expire's local value is 180 and the value of
session_cache_expire() is 5
--
Edit this bug report at http://bugs.php.net/?id=38278&edit=1
#38279 [Opn->Bgs]: mktime dont work right on all 31 day of a month
ID: 38279
Updated by: [EMAIL PROTECTED]
Reported By: support at ml-networld dot de
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Debian Sarge
PHP Version: 5.1.4
New Comment:
You need to set correct timezone.
Previous Comments:
[2006-08-01 07:11:19] support at ml-networld dot de
sorry,
i put the wrong phpversion
[2006-08-01 07:09:09] support at ml-networld dot de
Description:
On the 31 Juli, Oktober, Dezember the code below say that the lastmonth
is the current month. But on the 31 August it say that the last month is
jul. this code is an example code from nuntius on the site
http://de2.php.net/manual/de/function.mktime.php
Reproduce code:
---
$dateMinusOneMonth = mktime(0, 0, 0, date("m")-1, date("d"),
date("Y"));
$lastmonth = date("M", $dateMinusOneMonth);
echo $lastmonth;
Expected result:
on the 31 juli
jun
on the 31 oktober
sep
on the 31 dezember
nov
Actual result:
--
on the 31 juli
jul
on the 31 oktober
okt
on the 31 dezember
dez
--
Edit this bug report at http://bugs.php.net/?id=38279&edit=1
#38279 [Bgs]: mktime dont work right on all 31 day of a month
ID: 38279
User updated by: support at ml-networld dot de
Reported By: support at ml-networld dot de
Status: Bogus
Bug Type: Date/time related
Operating System: Debian Sarge
PHP Version: 5.1.4
New Comment:
i have the right timezome
Europe/Berlin
Previous Comments:
[2006-08-01 07:32:34] [EMAIL PROTECTED]
You need to set correct timezone.
[2006-08-01 07:11:19] support at ml-networld dot de
sorry,
i put the wrong phpversion
[2006-08-01 07:09:09] support at ml-networld dot de
Description:
On the 31 Juli, Oktober, Dezember the code below say that the lastmonth
is the current month. But on the 31 August it say that the last month is
jul. this code is an example code from nuntius on the site
http://de2.php.net/manual/de/function.mktime.php
Reproduce code:
---
$dateMinusOneMonth = mktime(0, 0, 0, date("m")-1, date("d"),
date("Y"));
$lastmonth = date("M", $dateMinusOneMonth);
echo $lastmonth;
Expected result:
on the 31 juli
jun
on the 31 oktober
sep
on the 31 dezember
nov
Actual result:
--
on the 31 juli
jul
on the 31 oktober
okt
on the 31 dezember
dez
--
Edit this bug report at http://bugs.php.net/?id=38279&edit=1
#38278 [Fbk->Opn]: session_cache_expire()'s value does not match phpinfo's session.cache_expire
ID: 38278
User updated by: winterain at gmail dot com
Reported By: winterain at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Windows
PHP Version: 4.4.2
New Comment:
this doesn't have to do with php.ini... i wanted to set shorter session
expire time for some webpages... but, other webpages should have the
default session expire time which is 180mins...
Note: (after executing the code... under phpinfo()'s session)
session.cache_limiter's local value is private
session.cache_limiter's master value is nocache
This is the expected and actual output for session.cache_limiter...
which is already correct.
But with session.cache_expire, the local value is not 5 but 180, and
the master value is 180 (which is the default).
Previous Comments:
[2006-08-01 07:29:36] [EMAIL PROTECTED]
Are you sure you changed correct php.ini and restarted the web server
after that?
[2006-08-01 03:25:44] winterain at gmail dot com
Description:
I have tried setting the session.cache_expire time to 5 mins with the
use of session_cache_expire(5) function... it does not work... the
session will still expire after 180mins which is the default value for
session.cache_expire.
Reproduce code:
---
session_cache_limiter('private');
session_cache_expire(5);
session_start();
phpinfo();
echo session_cache_expire();
Expected result:
after running the code, i'm expecting that phpinfo()'s
session.cache_expire's local value will be 5. And phpinfo()'s
session.cache_expire's local value should match the value returned by
session_cache_expire().
Actual result:
--
phpinfo's session.cache_expire's local value is 180 and the value of
session_cache_expire() is 5
--
Edit this bug report at http://bugs.php.net/?id=38278&edit=1
#38280 [NEW]: mysql_pconnect !!
From: sanry at now dot net dot cn Operating system: SUSE9.3 PHP version: 5.1.4 PHP Bug Type: MySQL related Bug description: mysql_pconnect !! Description: more than 6000 CLOSE_WAIT when using mysql_pconnect but mysql_connect is just 200, MySQL server and PHP not in the same server. MySQL server total 300 network connection when php WEB server has 6000 CLOSE_WAIT . Reproduce code: --- 1 0 61.145.112.137:4038461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4037261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4034061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4032261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4002961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4001561.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3999061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998861.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3993961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4015261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4014961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4014861.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4012261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3876961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3878061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3873461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3868961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3867461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3868761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3865961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3889461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3886061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3886161.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3884261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3884361.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3884661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3878761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3879661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3852761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3846961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3845161.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3841661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3842461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3864561.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3859261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3860061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3857661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3858761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3854861.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3853361.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3853961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3838661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3839261.145.112.136:3306 CLOSE_WAIT -- Edit bug report at http://bugs.php.net/?id=38280&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38280&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38280&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38280&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38280&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38280&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38280&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38280&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38280&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38280&r=support Expected behavior:http
#38280 [Opn->Bgs]: mysql_pconnect !!
ID: 38280 Updated by: [EMAIL PROTECTED] Reported By: sanry at now dot net dot cn -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: SUSE9.3 PHP Version: 5.1.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-08-01 08:48:12] sanry at now dot net dot cn Description: more than 6000 CLOSE_WAIT when using mysql_pconnect but mysql_connect is just 200, MySQL server and PHP not in the same server. MySQL server total 300 network connection when php WEB server has 6000 CLOSE_WAIT . Reproduce code: --- 1 0 61.145.112.137:4038461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4037261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4034061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4032261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4002961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4001561.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3999061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3998861.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3993961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4015261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4014961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4014861.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:4012261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3876961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3878061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3873461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3868961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3867461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3868761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3865961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3889461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3886061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3886161.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3884261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3884361.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3884661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3878761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3879661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3852761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3846961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3845161.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3841661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3842461.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3864561.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3859261.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3860061.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3857661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3858761.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3854861.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3853361.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3853961.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3838661.145.112.136:3306 CLOSE_WAIT tcp1 0 61.145.112.137:3839261.145.112.136:3306 CLOSE_WAIT -- Edit this bug report at http://bugs.php.net/?id=38280&edit
#38278 [Opn->Csd]: session_cache_expire()'s value does not match phpinfo's session.cache_expire
ID: 38278
Updated by: [EMAIL PROTECTED]
Reported By: winterain at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Windows
PHP Version: 4.4.2
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-08-01 07:49:23] winterain at gmail dot com
this doesn't have to do with php.ini... i wanted to set shorter session
expire time for some webpages... but, other webpages should have the
default session expire time which is 180mins...
Note: (after executing the code... under phpinfo()'s session)
session.cache_limiter's local value is private
session.cache_limiter's master value is nocache
This is the expected and actual output for session.cache_limiter...
which is already correct.
But with session.cache_expire, the local value is not 5 but 180, and
the master value is 180 (which is the default).
[2006-08-01 07:29:36] [EMAIL PROTECTED]
Are you sure you changed correct php.ini and restarted the web server
after that?
[2006-08-01 03:25:44] winterain at gmail dot com
Description:
I have tried setting the session.cache_expire time to 5 mins with the
use of session_cache_expire(5) function... it does not work... the
session will still expire after 180mins which is the default value for
session.cache_expire.
Reproduce code:
---
session_cache_limiter('private');
session_cache_expire(5);
session_start();
phpinfo();
echo session_cache_expire();
Expected result:
after running the code, i'm expecting that phpinfo()'s
session.cache_expire's local value will be 5. And phpinfo()'s
session.cache_expire's local value should match the value returned by
session_cache_expire().
Actual result:
--
phpinfo's session.cache_expire's local value is 180 and the value of
session_cache_expire() is 5
--
Edit this bug report at http://bugs.php.net/?id=38278&edit=1
#38279 [Bgs]: mktime dont work right on all 31 day of a month
ID: 38279
User updated by: support at ml-networld dot de
Reported By: support at ml-networld dot de
Status: Bogus
Bug Type: Date/time related
Operating System: Debian Sarge
PHP Version: 5.1.4
New Comment:
I test this problem in a xammp environment under my local windows, and
there i have the same problem.
Previous Comments:
[2006-08-01 07:37:02] support at ml-networld dot de
i have the right timezome
Europe/Berlin
[2006-08-01 07:32:34] [EMAIL PROTECTED]
You need to set correct timezone.
[2006-08-01 07:11:19] support at ml-networld dot de
sorry,
i put the wrong phpversion
[2006-08-01 07:09:09] support at ml-networld dot de
Description:
On the 31 Juli, Oktober, Dezember the code below say that the lastmonth
is the current month. But on the 31 August it say that the last month is
jul. this code is an example code from nuntius on the site
http://de2.php.net/manual/de/function.mktime.php
Reproduce code:
---
$dateMinusOneMonth = mktime(0, 0, 0, date("m")-1, date("d"),
date("Y"));
$lastmonth = date("M", $dateMinusOneMonth);
echo $lastmonth;
Expected result:
on the 31 juli
jun
on the 31 oktober
sep
on the 31 dezember
nov
Actual result:
--
on the 31 juli
jul
on the 31 oktober
okt
on the 31 dezember
dez
--
Edit this bug report at http://bugs.php.net/?id=38279&edit=1
#38273 [Fbk->Opn]: Incorrect return address after the execution of a signal handler?
ID: 38273 User updated by: axelluttgens at swing dot be Reported By: axelluttgens at swing dot be -Status: Feedback +Status: Open Bug Type: PCNTL related Operating System: Mac OS 10.4.7 PHP Version: 4.4.2 New Comment: Hello Tony, thanks again for your follow up! For various reasons, I am currently really stuck with PHP 4 here. In that sense, PHP 5 isn't an alternative for me yet. But perhaps were you considering a very precise point? Do you want me to try something else? TIA, Axel Previous Comments: [2006-07-31 20:13:53] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-07-31 19:40:17] axelluttgens at swing dot be Description: It seems there is a problem with the construction of the return address to be used after an interrupt handler. Now, I'm not sure whether the problem is a general one, or more precisely located in the socket_xxx() family of functions. I used the socket_select() function for building the example, as I needed a function whose execution is liable to be suspended until the occurence of an interrupt. But the "workaround" described hereafter anyway seems to reveal some misbehavior. Reproduce code: --- Create an executable file, say "sigtest.php", with following contents: #!/usr/local/bin/php Expected result: During execution of above file on the terminal, a break (^C) should result in: 1. the capture of SIGINT, and thus the execution of SaveINT(), 2. the continuation of execution after socket_select(), and thus the execution of HandleINT() consecutively to the call of PollSigs(). Actual result: -- [1] With above code, launching the executable yields: $ /Volumes/Data/Sources/sigtest.php ^C Warning: socket_select() unable to select [4]: Interrupted system call in /Volumes/Data/Sources/sigtest.php on line 31 Received SIGINT ^C Warning: socket_select() unable to select [4]: Interrupted system call in /Volumes/Data/Sources/sigtest.php on line 31 Handling SIGINT Received SIGINT [2] Now, uncomment the # $err = $err; line in the source and launch the executable again: $ /Volumes/Data/Sources/sigtest.php ^C Warning: socket_select() unable to select [4]: Interrupted system call in /Volumes/Data/Sources/sigtest.php on line 31 Received SIGINT Handling SIGINT ^C Warning: socket_select() unable to select [4]: Interrupted system call in /Volumes/Data/Sources/sigtest.php on line 31 Received SIGINT Handling SIGINT The dummy instruction (ie, $err = $err;) thus allows to restore exepected behavior. -- Edit this bug report at http://bugs.php.net/?id=38273&edit=1
#38282 [NEW]: Add bzfile function
From: andrew at bramp dot freeserve dot co dot uk Operating system: PHP version: 5.1.4 PHP Bug Type: Feature/Change Request Bug description: Add bzfile function Description: I recently wanted to use bzfile(), just as I've used gzfile() and file(), however I found there was no bzfile(). So if possible I'm requesting this as a feature. Thanks Andrew -- Edit bug report at http://bugs.php.net/?id=38282&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38282&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38282&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38282&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38282&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38282&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38282&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38282&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38282&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38282&r=support Expected behavior:http://bugs.php.net/fix.php?id=38282&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38282&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38282&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38282&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38282&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38282&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38282&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38282&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38282&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38282&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38282&r=mysqlcfg
#38114 [NoF->Opn]: Warning: ftp_put(): User foobar logged in.
ID: 38114 User updated by: bugada at blu dot it Reported By: bugada at blu dot it -Status: No Feedback +Status: Open Bug Type: FTP related Operating System: Windows Server 2003 PHP Version: 4.4.2 New Comment: Sorry, I can't use php 5 because the application works with php 4 only. And I can't figure out why you are suggesting to upgrade to php5 while is clearly stated that the bug is on php4. Previous Comments: [2006-07-30 01:00:02] 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". [2006-07-22 12:15:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-07-16 16:15:55] bugada at blu dot it Description: I'm using ftp_get and ftp_put functions to exchange small text files between a Windows Server 2003 Web Edition machine and Windows NT 4.0 mounting a Microsoft FTP Service (Version 4.0). In some cases (randomly I think) the ftp_get (or ftp_put) command prints this and returns FALSE. Warning: ftp_get(): User foobar logged in. in D:\myapppath\ftp.php on line 68 This is the ftp server log: [17:45:23] 220 dmzmibrz Microsoft FTP Service (Version 4.0). [17:45:23] USER foobar [17:45:23] 331 Password required for foobar. [17:45:23] PASS (hidden) [17:45:23] 230- Welcome to dummy.tld [17:45:23] 230 User hrdkft01 logged in. I can't reproduce it systematically it but it often occurs. It seems that php ftp functions don't recognize the Welcome message (230) correctly. -- Edit this bug report at http://bugs.php.net/?id=38114&edit=1
#38114 [Opn->Fbk]: Warning: ftp_put(): User foobar logged in.
ID: 38114 Updated by: [EMAIL PROTECTED] Reported By: bugada at blu dot it -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Windows Server 2003 PHP Version: 4.4.2 New Comment: It's clearly stated that Jani wanted you to TRY PHP5 and not to UPGRADE your PHP. Previous Comments: [2006-08-01 12:07:38] bugada at blu dot it Sorry, I can't use php 5 because the application works with php 4 only. And I can't figure out why you are suggesting to upgrade to php5 while is clearly stated that the bug is on php4. [2006-07-30 01:00:02] 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". [2006-07-22 12:15:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-07-16 16:15:55] bugada at blu dot it Description: I'm using ftp_get and ftp_put functions to exchange small text files between a Windows Server 2003 Web Edition machine and Windows NT 4.0 mounting a Microsoft FTP Service (Version 4.0). In some cases (randomly I think) the ftp_get (or ftp_put) command prints this and returns FALSE. Warning: ftp_get(): User foobar logged in. in D:\myapppath\ftp.php on line 68 This is the ftp server log: [17:45:23] 220 dmzmibrz Microsoft FTP Service (Version 4.0). [17:45:23] USER foobar [17:45:23] 331 Password required for foobar. [17:45:23] PASS (hidden) [17:45:23] 230- Welcome to dummy.tld [17:45:23] 230 User hrdkft01 logged in. I can't reproduce it systematically it but it often occurs. It seems that php ftp functions don't recognize the Welcome message (230) correctly. -- Edit this bug report at http://bugs.php.net/?id=38114&edit=1
#38272 [Bgs]: Includes from one web instance appearing in another
ID: 38272 User updated by: djh146 at psu dot edu Reported By: djh146 at psu dot edu Status: Bogus Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.4.2 New Comment: Bah! Simple issue. What was strange was that behavior was as expected until a hardware replacement. Not sure how it was working until then! Thanks Previous Comments: [2006-07-31 18:36:54] [EMAIL PROTECTED] That's pretty easy to explain: your B instance has A's path in include_path, so when you use relative path like "includes/header.php", PHP looks for "header.php" in its include_path and finds the one from A. This is apparently expected behaviour until you can prove I'm wrong (we'd you to try PHP4.4.3 and provide a reproduce case in this case). [2006-07-31 18:28:06] djh146 at psu dot edu Description: I am running PHP as a CGI under IIS 5. There are multiple web instances running on the server. Two are PHP applications that use include files (i.e. includes/header.php, includes/footer.php, etc.) that are included on pages as . Both applications use the same code structure. When running these applications, I am seeing the include files from one website instance appearing as the includes on another instance. It appears to be only in one direction. I encountered a similar problem when objects of the same name were being treated ambigiously. This was discovered to be a problem occuring using the ISAPI module in IIS and shared process space, which is why I moved to the CGI configuration. Could this be a similar problem? The two sites are running under the same IP address with different headers, and the source for each are located in seperate folders on the same drive. Expected result: The sites should (and have) run without interference from each other. Actual result: -- Site A's include header and footer will appear in Site B's output. -- Edit this bug report at http://bugs.php.net/?id=38272&edit=1
#38279 [Bgs]: mktime dont work right on all 31 day of a month
ID: 38279
Updated by: [EMAIL PROTECTED]
Reported By: support at ml-networld dot de
Status: Bogus
Bug Type: Date/time related
Operating System: Debian Sarge
PHP Version: 5.1.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Clue: what are the 31sts of June, September and November?
Previous Comments:
[2006-08-01 09:07:01] support at ml-networld dot de
I test this problem in a xammp environment under my local windows, and
there i have the same problem.
[2006-08-01 07:37:02] support at ml-networld dot de
i have the right timezome
Europe/Berlin
[2006-08-01 07:32:34] [EMAIL PROTECTED]
You need to set correct timezone.
[2006-08-01 07:11:19] support at ml-networld dot de
sorry,
i put the wrong phpversion
[2006-08-01 07:09:09] support at ml-networld dot de
Description:
On the 31 Juli, Oktober, Dezember the code below say that the lastmonth
is the current month. But on the 31 August it say that the last month is
jul. this code is an example code from nuntius on the site
http://de2.php.net/manual/de/function.mktime.php
Reproduce code:
---
$dateMinusOneMonth = mktime(0, 0, 0, date("m")-1, date("d"),
date("Y"));
$lastmonth = date("M", $dateMinusOneMonth);
echo $lastmonth;
Expected result:
on the 31 juli
jun
on the 31 oktober
sep
on the 31 dezember
nov
Actual result:
--
on the 31 juli
jul
on the 31 oktober
okt
on the 31 dezember
dez
--
Edit this bug report at http://bugs.php.net/?id=38279&edit=1
#38279 [Bgs->Csd]: mktime dont work right on all 31 day of a month
ID: 38279 User updated by: support at ml-networld dot de Reported By: support at ml-networld dot de -Status: Bogus +Status: Closed Bug Type: Date/time related Operating System: Debian Sarge PHP Version: 5.1.4 New Comment: thx. Previous Comments: [2006-08-01 13:01:09] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Clue: what are the 31sts of June, September and November? [2006-08-01 09:07:01] support at ml-networld dot de I test this problem in a xammp environment under my local windows, and there i have the same problem. [2006-08-01 07:37:02] support at ml-networld dot de i have the right timezome Europe/Berlin [2006-08-01 07:32:34] [EMAIL PROTECTED] You need to set correct timezone. [2006-08-01 07:11:19] support at ml-networld dot de sorry, i put the wrong phpversion 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/38279 -- Edit this bug report at http://bugs.php.net/?id=38279&edit=1
#37472 [Com]: ming 0.3.0 does not compile with php 4.4.2
ID: 37472 Comment by: d3m1g0d at gmail dot com Reported By: cs at tequila dot co dot jp Status: No Feedback Bug Type: Compile Failure Operating System: Linux PHP Version: 4.4.2 New Comment: hi, im experiencing the same problem on centos 4.3 final. i've also tried the current snapshot: /bin/sh /usr/src/redhat/tmp/BUILD/php4-4.4.2/build-cgi/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/ncurses/ -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ncurses/ -DPHP_ATOM_INC -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/build-cgi/include -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/build-cgi/main -I/usr/src/redhat/tmp/BUILD/php4-4.4.2 -I/usr/kerberos/include -I/usr/include/pcre -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/mbstring/mbregex -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/mbstring/libmbfl -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/ncurses -I/opt/oracle/product/9.0.2/rdbms/public -I/opt/oracle/product/9.0.2/rdbms/demo -I/usr/include/pspell -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/build-cgi/TSRM -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/build-cgi/Zend -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/main -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/Zend -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/TSRM -I/usr/src/redhat/tmp/BUILD/php4-4.4.2/build-cgi/-O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -fno-strict-aliasing -Wall -prefer-pic -c /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ncurses/ncurses_fe.c -o ext/ncurses/ncurses_fe.lo /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c: In function `zif_swfbitmap_init': /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c:323: warning: assignment from incompatible pointer type /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c: In function `zif_swfmovie_output': /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c:1467: error: too many arguments to function `SWFMovie_output' /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c: In function `zif_swfmovie_saveToFile': /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c:1516: error: too many arguments to function `SWFMovie_output' /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c: In function `zif_swfmovie_save': /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c:1561: error: too many arguments to function `SWFMovie_output' /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c:1575: error: too many arguments to function `SWFMovie_output' /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c: In function `zif_swftextfield_setFont': /usr/src/redhat/tmp/BUILD/php4-4.4.2/ext/ming/ming.c:2597: warning: passing arg 2 of `SWFTextField_setFont' from incompatible pointer type make: *** [ext/ming/ming.lo] Error 1 Previous Comments: [2006-05-28 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". [2006-05-20 21:17:27] erkintek at fotograf dot web dot tr problem continuing with following output gcc -Iext/ming/ -I/home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ -DPHP_ATOM_INC -I/home/erkintek/sil/php/php4-STABLE-200605202030/include -I/home/erkintek/sil/php/php4-STABLE-200605202030/main -I/home/erkintek/sil/php/php4-STABLE-200605202030 -I/usr/include/libxml2 -I/usr/local/include -I/home/erkintek/sil/php/php4-STABLE-200605202030/ext/xml/expat -I/home/erkintek/sil/php/php4-STABLE-200605202030/TSRM -I/home/erkintek/sil/php/php4-STABLE-200605202030/Zend-g -O2 -c /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c -o ext/ming/ming.o && echo > ext/ming/ming.lo /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c: In function `zif_swfbitmap_init': /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c:323: warning: assignment from incompatible pointer type /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c: In function `zif_swfmovie_output': /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c:1467: error: too many arguments to function `SWFMovie_output' /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c: In function `zif_swfmovie_saveToFile': /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c:1516: error: too many arguments to function `SWFMovie_output' /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c: In function `zif_swfmovie_save': /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c:1561: error: too many arguments to function `SWFMovie_output' /home/erkintek/sil/php/php4-STABLE-200605202030/ext/ming/ming.c:1575: error: too many arguments to function `SWFMovie_output' /home/erkintek/s
#38279 [Csd->Bgs]: mktime dont work right on all 31 day of a month
ID: 38279 Updated by: [EMAIL PROTECTED] Reported By: support at ml-networld dot de -Status: Closed +Status: Bogus Bug Type: Date/time related Operating System: Debian Sarge PHP Version: 5.1.4 New Comment: . Previous Comments: [2006-08-01 13:45:05] support at ml-networld dot de thx. [2006-08-01 13:01:09] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Clue: what are the 31sts of June, September and November? [2006-08-01 09:07:01] support at ml-networld dot de I test this problem in a xammp environment under my local windows, and there i have the same problem. [2006-08-01 07:37:02] support at ml-networld dot de i have the right timezome Europe/Berlin [2006-08-01 07:32:34] [EMAIL PROTECTED] You need to set correct timezone. 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/38279 -- Edit this bug report at http://bugs.php.net/?id=38279&edit=1
#38178 [Asn->Fbk]: Problem with parameter detection in queries (HY093)
ID: 38178
Updated by: [EMAIL PROTECTED]
Reported By: gerald at copix dot org
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows
PHP Version: 5.1.4
Assigned To: wez
New Comment:
What database driver are you using?
Previous Comments:
[2006-07-21 16:08:00] gerald at copix dot org
Description:
Using PDO, a simple insert query does not work with "prepare / execute"
but works fine using "exec"
This exact query does work correctly if I remove the text '\r\n' at its
end.
The query is :
'INSERT INTO myTable VALUES (\'xml:lang="fr" lang="fr">\r\n\')'
It may be related to the following bugs :
#36923 & #37646
Reproduce code:
---
//FOLLOWING DOES NOT WORK
$stmt = $pdo->prepare ('INSERT INTO myTable VALUES (\'xml:lang="fr"
lang="fr">\r\n\')');
if (! $stmt->execute ()){
print_r ($stmt->errorInfo ());//contains Array ( [0] => HY093 )
}
//FOLLOWING CODE IS OK (using exec)
if (! $pdo->exec ('INSERT INTO myTable VALUES (\'xml:lang="fr"
lang="fr">\r\n\')')){
print_r ($pdo->errorInfo ());
}
//FOLLOWING CODE IS OK (removed \r\n at the end of the query)
$stmt = $pdo->prepare ('INSERT INTO myTable VALUES (\'xml:lang="fr"
lang="fr">\')');
$stmt->execute ();//OK
Expected result:
PDO should insert the value 'xml:lang="fr" lang="fr">\r\n' in the
myTable table, wish is
CREATE TABLE `myTable` (
`test` VARCHAR( 255 ) NOT NULL
)
Actual result:
--
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY093]: Invalid parameter number: no parameters were bound in
C:\Program Files\wamp\www\test_3\www\index.php on line 40
--
Edit this bug report at http://bugs.php.net/?id=38178&edit=1
#38269 [Opn->Csd]: fopen wrapper doesn't fail on invalid hostname with curlwrappers enabled
ID: 38269 Updated by: [EMAIL PROTECTED] Reported By: blueshade at wave460 dot net -Status: Open +Status: Closed Bug Type: Streams related Operating System: debian sarge on linux 2.4.27 PHP Version: 5.1.4 New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-07-31 14:46:08] blueshade at wave460 dot net Description: when compiled with "--with-curlwrappers", php 5.1.4 fails to fail an fopen request when you provide it with a uri containing an invalid host name, when recompiled without "--with-curlwrappers", it fails as expected... this results in php invalidly returing a valid fopen resource even if the remote host is unreachable (e.g. because of a network problem) Reproduce code: --- http://non.existent.host', 'rb'); print_r($file); echo "\n"; ?> Expected result: it should display a warning (if enabled) and return "false" in $file Actual result: -- with "--with-curlwrappers", it returns "Resource id #5" in $file and doesn't warn of an error whatsoever -- Edit this bug report at http://bugs.php.net/?id=38269&edit=1
#38283 [NEW]: mysql_pconnect can't reuse the connections
From: sanry at now dot net dot cn
Operating system: SUSE9.3 x86_64
PHP version: 5.1.4
PHP Bug Type: MySQL related
Bug description: mysql_pconnect can't reuse the connections
Description:
mysql_pconnect create too many connections ,
not using the same connection in x86_64
(web server and mysql server not in the same computer)
I have test in 32bit system is okay,
both using the same mysql5.0.22
Reproduce code:
---
';
echo mysql_stat($db).'';
$t2=getmicrotime();
$tt=$t2-$t1;
$sql="SHOW PROCESSLIST ";
$res=mysql_query($sql);
if($res){
$dbstatus=mysql_num_rows($res);
}else $dbstatus=mysql_error();
//mysql_close($db);
echo "there are ".$dbstatus." connections ";
echo "time for connect is $tt ***";
?>
--
Edit bug report at http://bugs.php.net/?id=38283&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38283&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38283&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38283&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38283&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38283&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38283&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38283&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38283&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38283&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38283&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38283&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38283&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38283&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38283&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38283&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38283&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38283&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38283&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38283&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38283&r=mysqlcfg
#38284 [NEW]: user_dir Does not work
From: egingell at sisna dot com Operating system: Windows XP Pro PHP version: 4.4.2 PHP Bug Type: IIS related Bug description: user_dir Does not work Description: Setting the user_dir directive in php.ini has no affect. When attempting to go to http://localhost/~user/ a 404 Not Found error occurs. I can't find *any* documentation on what to set that directive to. I've tried "public_html", "C:\Documents and Settings", and "C:\Documents and Settings\*\public_html". None of which produced the desired results. I'm using IIS 6 to serve PHP 4.4.2 files. Expected result: A web page. Actual result: -- 404 File Not Found -- Edit bug report at http://bugs.php.net/?id=38284&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38284&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38284&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38284&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38284&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38284&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38284&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38284&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38284&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38284&r=support Expected behavior:http://bugs.php.net/fix.php?id=38284&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38284&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38284&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38284&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38284&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38284&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38284&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38284&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38284&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38284&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38284&r=mysqlcfg
#37709 [Asn->Csd]: valgrind reports invalid reads in PDO::errorCode()
ID: 37709 Updated by: [EMAIL PROTECTED] Reported By: tony2001 at phpclub dot net -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: Linux PHP Version: 5CVS-2006-06-06 (CVS) Assigned To: iliaa New Comment: I cannot reproduce this problem and the disable-zend-memory- manager option is no longer available :/ Previous Comments: [2006-06-26 18:49:25] [EMAIL PROTECTED] Ilia, unfortunately your patch didn't help and I can still see the same invalid reads. Apparently it's reproducible only using --disable-zend-memory-manager. [2006-06-07 03:33:47] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. [2006-06-06 09:07:36] tony2001 at phpclub dot net Description: ==22003== Invalid read of size 1 ==22003==at 0x4906752: strlen (mac_replace_strmem.c:243) ==22003==by 0x4F776E: zim_PDO_errorCode (pdo_dbh.c:955) ==22003==by 0x69B845: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==22003==by 0x69B072: execute (zend_vm_execute.h:92) ==22003==by 0x67A634: zend_execute_scripts (zend.c:1100) ==22003==by 0x632AC0: php_execute_script (main.c:1747) ==22003==by 0x70130D: main (php_cli.c:1089) ==22003== Address 0x730A474 is 148 bytes inside a block of size 344 free'd ==22003==at 0x49055DD: free (vg_replace_malloc.c:235) ==22003==by 0x697867: zend_objects_store_del_ref_by_handle (zend_objects_API.c:196) ==22003==by 0x69787D: zend_objects_store_del_ref (zend_objects_API.c:158) ==22003==by 0x4F7B4F: zim_PDO_query (zend_variables.h:35) ==22003==by 0x69B845: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==22003==by 0x69B072: execute (zend_vm_execute.h:92) ==22003==by 0x67A634: zend_execute_scripts (zend.c:1100) ==22003==by 0x632AC0: php_execute_script (main.c:1747) ==22003==by 0x70130D: main (php_cli.c:1089) ==22003== Invalid read of size 1 ==22003==at 0x4906AF7: memcpy (mac_replace_strmem.c:394) ==22003==by 0x65D557: zend_strndup (zend_alloc.c:439) ==22003==by 0x4F7710: zim_PDO_errorCode (pdo_dbh.c:958) ==22003==by 0x69B845: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==22003==by 0x69B072: execute (zend_vm_execute.h:92) ==22003==by 0x67A634: zend_execute_scripts (zend.c:1100) ==22003==by 0x632AC0: php_execute_script (main.c:1747) ==22003==by 0x70130D: main (php_cli.c:1089) ==22003== Address 0x730A478 is 152 bytes inside a block of size 344 free'd ==22003==at 0x49055DD: free (vg_replace_malloc.c:235) ==22003==by 0x697867: zend_objects_store_del_ref_by_handle (zend_objects_API.c:196) ==22003==by 0x69787D: zend_objects_store_del_ref (zend_objects_API.c:158) ==22003==by 0x4F7B4F: zim_PDO_query (zend_variables.h:35) ==22003==by 0x69B845: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==22003==by 0x69B072: execute (zend_vm_execute.h:92) ==22003==by 0x67A634: zend_execute_scripts (zend.c:1100) ==22003==by 0x632AC0: php_execute_script (main.c:1747) ==22003==by 0x70130D: main (php_cli.c:1089) Note that PDO::query() *destroys* statement object as well as statement handle when query fails. So PDO::errorCode() operates on already destroyed statement handle. Reproduce code: --- See ext/pdo/tests/bug_34687.phpt. I've reproduced it with sqlite2::memory, but that shouldn't matter. Expected result: No invalid reads? -- Edit this bug report at http://bugs.php.net/?id=37709&edit=1
#38168 [Asn->Csd]: PDO Exception Causes PHP Crash
ID: 38168 Updated by: [EMAIL PROTECTED] Reported By: php at unfit dot org -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.1.4 Assigned To: wez New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-07-24 16:40:03] [EMAIL PROTECTED] ==21175== Invalid write of size 4 ==21175==at 0x80C50D3: pgsql_stmt_param_hook (pgsql_statement.c:305) ==21175==by 0x80BBD07: dispatch_param_event (pdo_stmt.c:149) ==21175==by 0x80BC690: zim_PDOStatement_execute (pdo_stmt.c:447) ==21175==by 0x81B79C1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==21175==by 0x81B7F0D: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==21175==by 0x81B75D4: execute (zend_vm_execute.h:92) ==21175==by 0x819A09A: zend_execute_scripts (zend.c:1095) ==21175==by 0x8153984: php_execute_script (main.c:1759) ==21175==by 0x81FEA23: main (php_cli.c:1097) ==21175== Address 0x4D96418 is 4 bytes after a block of size 4 alloc'd ==21175==at 0x401C451: malloc (vg_replace_malloc.c:149) ==21175==by 0x81807AD: _emalloc (zend_alloc.c:1577) ==21175==by 0x8180A93: _ecalloc (zend_alloc.c:1675) ==21175==by 0x80C4CE2: pgsql_stmt_param_hook (pgsql_statement.c:249) ==21175==by 0x80BBD07: dispatch_param_event (pdo_stmt.c:149) ==21175==by 0x80BC690: zim_PDOStatement_execute (pdo_stmt.c:447) ==21175==by 0x81B79C1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==21175==by 0x81B7F0D: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==21175==by 0x81B75D4: execute (zend_vm_execute.h:92) ==21175==by 0x819A09A: zend_execute_scripts (zend.c:1095) ==21175==by 0x8153984: php_execute_script (main.c:1759) ==21175==by 0x81FEA23: main (php_cli.c:1097) ==21175== ==21175== Invalid write of size 4 ==21175==at 0x80C50F1: pgsql_stmt_param_hook (pgsql_statement.c:306) ==21175==by 0x80BBD07: dispatch_param_event (pdo_stmt.c:149) ==21175==by 0x80BC690: zim_PDOStatement_execute (pdo_stmt.c:447) ==21175==by 0x81B79C1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==21175==by 0x81B7F0D: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==21175==by 0x81B75D4: execute (zend_vm_execute.h:92) ==21175==by 0x819A09A: zend_execute_scripts (zend.c:1095) ==21175==by 0x8153984: php_execute_script (main.c:1759) ==21175==by 0x81FEA23: main (php_cli.c:1097) ==21175== Address 0x4D96450 is 4 bytes after a block of size 4 alloc'd ==21175==at 0x401C451: malloc (vg_replace_malloc.c:149) ==21175==by 0x81807AD: _emalloc (zend_alloc.c:1577) ==21175==by 0x8180A93: _ecalloc (zend_alloc.c:1675) ==21175==by 0x80C4D12: pgsql_stmt_param_hook (pgsql_statement.c:252) ==21175==by 0x80BBD07: dispatch_param_event (pdo_stmt.c:149) ==21175==by 0x80BC690: zim_PDOStatement_execute (pdo_stmt.c:447) ==21175==by 0x81B79C1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==21175==by 0x81B7F0D: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==21175==by 0x81B75D4: execute (zend_vm_execute.h:92) ==21175==by 0x819A09A: zend_execute_scripts (zend.c:1095) ==21175==by 0x8153984: php_execute_script (main.c:1759) ==21175==by 0x81FEA23: main (php_cli.c:1097) ==21175== ==21175== Invalid write of size 4 ==21175==at 0x80C5106: pgsql_stmt_param_hook (pgsql_statement.c:307) ==21175==by 0x80BBD07: dispatch_param_event (pdo_stmt.c:149) ==21175==by 0x80BC690: zim_PDOStatement_execute (pdo_stmt.c:447) ==21175==by 0x81B79C1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==21175==by 0x81B7F0D: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==21175==by 0x81B75D4: execute (zend_vm_execute.h:92) ==21175==by 0x819A09A: zend_execute_scripts (zend.c:1095) ==21175==by 0x8153984: php_execute_script (main.c:1759) ==21175==by 0x81FEA23: main (php_cli.c:1097) ==21175== Address 0x4D96488 is 4 bytes after a block of size 4 alloc'd ==21175==at 0x401C451: malloc (vg_replace_malloc.c:149) ==21175==by 0x81807AD: _emalloc (zend_alloc.c:1577) ==21175==by 0x8180A93: _ecalloc (zend_alloc.c:1675) ==21175==by 0x80C4D42: pgsql_stmt_param_hook (pgsql_statement.c:255) ==21175==by 0x80BBD07: dispatch_param_event (pdo_stmt.c:149) ==21175==by 0x80BC690: zim_PDOStatement_execute (pdo_stmt.c:447) ==21175==by 0x81B79C1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==21175==by 0x81B7F0D: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==21175==by 0x81B75D4: execute (zend_vm_execute.h:92) ==21175==
#38285 [NEW]: php.ini configuration to limit the maximum buffer size doesn't work.
From: bref at instinctiv-e dot com
Operating system: Linux 2.6.17
PHP version: 5.1.4
PHP Bug Type: Output Control
Bug description: php.ini configuration to limit the maximum buffer size
doesn't work.
Description:
Output buffering doesn't respect the maximum limit as set in php.ini in
php 5.1.4 plus some earlier versions.
output_buffering=xxx
In fact it is possible to go well past the limit and consume the entire
memory allocated to the script by memory_limit causing the script to
halt.
snippet from php.ini -
If you wish to limit the size of the buffer
; to a certain size - you can use a maximum number of bytes instead of
'On', as
; a value for this directive (e.g., output_buffering=4096).
Reproduce code:
---
ini_set("zlib.output_compression",0);
ini_set("max_execution_time",5);
// set this to larger than your output_buffering=xxx limit
ini_set("memory_limit",'3M');
echo 'Maximum buffer size as set in php.ini output_buffering: ',
$limit = ini_get("output_buffering"),
'';
echo '','Starting OB test...','';
ob_start();
// fill up the buffer 10 bytes beyond the supposed limit
for($i=0;$i<($limit+10);$i++) { echo 'a'; }
$size = ob_get_length();
ob_end_flush();
Expected result:
Expected the output buffer to respect the maximum bytes cap as set out in
php.ini output_buffering=
Actual result:
--
The buffer keeps on growing past the set limit, until it fills the
memory_limit or max_execution_time limits and terminates the script.
--
Edit bug report at http://bugs.php.net/?id=38285&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38285&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38285&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38285&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38285&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38285&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38285&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38285&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38285&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38285&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38285&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38285&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38285&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38285&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38285&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38285&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38285&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38285&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38285&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38285&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38285&r=mysqlcfg
#38285 [Opn->Bgs]: php.ini configuration to limit the maximum buffer size doesn't work.
ID: 38285
Updated by: [EMAIL PROTECTED]
Reported By: bref at instinctiv-e dot com
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Linux 2.6.17
PHP Version: 5.1.4
New Comment:
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
http://php.net/ob_start
INI output_buffering= starts its own output buffer
Previous Comments:
[2006-08-01 17:33:37] bref at instinctiv-e dot com
Description:
Output buffering doesn't respect the maximum limit as set in php.ini in
php 5.1.4 plus some earlier versions.
output_buffering=xxx
In fact it is possible to go well past the limit and consume the entire
memory allocated to the script by memory_limit causing the script to
halt.
snippet from php.ini -
If you wish to limit the size of the buffer
; to a certain size - you can use a maximum number of bytes instead of
'On', as
; a value for this directive (e.g., output_buffering=4096).
Reproduce code:
---
ini_set("zlib.output_compression",0);
ini_set("max_execution_time",5);
// set this to larger than your output_buffering=xxx limit
ini_set("memory_limit",'3M');
echo 'Maximum buffer size as set in php.ini output_buffering: ',
$limit = ini_get("output_buffering"),
'';
echo '','Starting OB test...','';
ob_start();
// fill up the buffer 10 bytes beyond the supposed limit
for($i=0;$i<($limit+10);$i++) { echo 'a'; }
$size = ob_get_length();
ob_end_flush();
Expected result:
Expected the output buffer to respect the maximum bytes cap as set out
in php.ini output_buffering=
Actual result:
--
The buffer keeps on growing past the set limit, until it fills the
memory_limit or max_execution_time limits and terminates the script.
--
Edit this bug report at http://bugs.php.net/?id=38285&edit=1
#38287 [NEW]: static variables mess up global vars
From: steemann at globalpark dot de
Operating system: Linux 2.6.12-10-686
PHP version: 5.2.0RC1
PHP Bug Type: Class/Object related
Bug description: static variables mess up global vars
Description:
Variables in the global scope seem to keep corrupted when using static
properties/variables.
The script below has a global variable $not_there which is supposed to be
NULL
as it is not set. It is NULL when var_dumping it.
Although the variable is not set by the script, the variable value changes
during
execution so the script evaluates
if ($not_there["invalid_var"]))
to true obviously. When printing a hash of the variable ("use_authmodule"
which
does not exist), the variable seems to be an array but it should be NULL.
btw: magic_quotes_gpc is turned on.
Reproduce code:
---
something::do_something((int) $argv[1]);
// $not_there is really NULL
var_dump($not_there);
// error occurs here: execution should never get inside the if condition
because $not_there is NULL
if ($not_there["invalid_var"])
{
// will print NULL (which is ok, but execution should never get here if
the value is NULL)
var_dump($not_there["use_authmodule"]);
// will print "PATH:Array"
print "PATH:".$not_there["use_authmodule"];
}
class something
{
protected static $static_var=array();
public static function get_object()
{
static $object=NULL;
if ($object===NULL)
$object=new something;
return $object;
}
public static function do_something($version=0)
{
if ($version==0)
{
// $argv[1]==0: this will cause the error
foreach (array("g"=>&$_GET,"p"=>&$_POST,"r"=>&$_REQUEST) as
$var_name=>$super_global)
self::get_object()->static_var[]=$var_name;
} // end of version 0
if ($version==1)
{
// $argv[1]==1: this does the same but will not cause the error
$obj=self::get_object();
foreach (array("g"=>&$_GET,"p"=>&$_POST,"r"=>&$_REQUEST) as
$var_name=>$super_global)
$obj->static_var[]=$var_name;
} // end of version 1
} // end of do_something method
} // end of class something
Expected result:
expected result for $argv[1]==0:
NULL
result for $argv[1]==1:
NULL
Actual result:
--
Call the script above on the command line with $argv[1]=0.
Script execution gets into the "if ($not_there...)" part as the global
variable
$not_there gets corrupted.
result is:
NULL
NULL
PATH:Array
result for $argv[1]=1:
NULL
So the problem does not occur if the script is called with $argv[1] = 1.
The $argv interpretation and actual difference in the code is in method
do_something() of class "something".
I know the static property $static_var of class "something" should not be
accessed via -> because it is static, but the code worked fine in PHP 5.1
and also works fine when using version 1 ($argv[1]=1).
--
Edit bug report at http://bugs.php.net/?id=38287&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38287&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38287&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38287&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38287&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38287&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38287&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38287&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38287&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38287&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38287&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38287&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38287&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38287&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38287&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38287&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38287&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38287&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38287&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38287&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38287&r=mysqlcfg
#38287 [Opn->Asn]: static variables mess up global vars
ID: 38287
Updated by: [EMAIL PROTECTED]
Reported By: steemann at globalpark dot de
-Status: Open
+Status: Assigned
Bug Type: Class/Object related
Operating System: Linux 2.6.12-10-686
PHP Version: 5.2.0RC1
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, could you please take a look at it?
There are also several leaks, which seem to be related to the issue.
Previous Comments:
[2006-08-01 18:57:16] steemann at globalpark dot de
Description:
Variables in the global scope seem to keep corrupted when using static
properties/variables.
The script below has a global variable $not_there which is supposed to
be NULL
as it is not set. It is NULL when var_dumping it.
Although the variable is not set by the script, the variable value
changes during
execution so the script evaluates
if ($not_there["invalid_var"]))
to true obviously. When printing a hash of the variable
("use_authmodule" which
does not exist), the variable seems to be an array but it should be
NULL.
btw: magic_quotes_gpc is turned on.
Reproduce code:
---
something::do_something((int) $argv[1]);
// $not_there is really NULL
var_dump($not_there);
// error occurs here: execution should never get inside the if
condition because $not_there is NULL
if ($not_there["invalid_var"])
{
// will print NULL (which is ok, but execution should never get here
if the value is NULL)
var_dump($not_there["use_authmodule"]);
// will print "PATH:Array"
print "PATH:".$not_there["use_authmodule"];
}
class something
{
protected static $static_var=array();
public static function get_object()
{
static $object=NULL;
if ($object===NULL)
$object=new something;
return $object;
}
public static function do_something($version=0)
{
if ($version==0)
{
// $argv[1]==0: this will cause the error
foreach (array("g"=>&$_GET,"p"=>&$_POST,"r"=>&$_REQUEST) as
$var_name=>$super_global)
self::get_object()->static_var[]=$var_name;
} // end of version 0
if ($version==1)
{
// $argv[1]==1: this does the same but will not cause the error
$obj=self::get_object();
foreach (array("g"=>&$_GET,"p"=>&$_POST,"r"=>&$_REQUEST) as
$var_name=>$super_global)
$obj->static_var[]=$var_name;
} // end of version 1
} // end of do_something method
} // end of class something
Expected result:
expected result for $argv[1]==0:
NULL
result for $argv[1]==1:
NULL
Actual result:
--
Call the script above on the command line with $argv[1]=0.
Script execution gets into the "if ($not_there...)" part as the global
variable
$not_there gets corrupted.
result is:
NULL
NULL
PATH:Array
result for $argv[1]=1:
NULL
So the problem does not occur if the script is called with $argv[1] =
1.
The $argv interpretation and actual difference in the code is in method
do_something() of class "something".
I know the static property $static_var of class "something" should not
be
accessed via -> because it is static, but the code worked fine in PHP
5.1
and also works fine when using version 1 ($argv[1]=1).
--
Edit this bug report at http://bugs.php.net/?id=38287&edit=1
#38288 [NEW]: msvcrt dependency problem in VC++ 8.0
From: rafaelhfaria at terra dot com dot br
Operating system: Windows XP Pro
PHP version: 5.1.4
PHP Bug Type: Compile Failure
Bug description: msvcrt dependency problem in VC++ 8.0
Description:
I'm compiling PHP 5.4.1 with Microsoft Visual Studio 2005.
But with msvcrt I get an unwanted dependency of "msvcr80.dll". I tried
compile with static link option: "/MT" in place of "/MD" (using libcmt).
But without success...
--- Error Log (with libcmt and without msvcrt):
Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Creating library Release_TS\php5ts.lib and object
Release_TS\php5ts.exp
zend_strtod.obj : error LNK2019: unresolved external symbol __HUGE
referenced in function _zend_strtod
math.obj : error LNK2001: unresolved external symbol __HUGE
php_variables.obj : error LNK2019: unresolved external symbol __environ
referenced in function __php_import_environment_variables
basic_functions.obj : error LNK2001: unresolved external symbol
__environinfo.obj : error LNK2001: unresolved external symbol __environ
Release_TS\php5ts.dll : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: '"C:\Arquivos de programas\Microsoft Visual
Studio 8\VC\BIN\link.exe"' : return code '0x460'
Stop.
---
Peace of code from "configure.js":
ADD_FLAG("CFLAGS", "/LD /MD /W3 /Ox /D NDebug /D NDEBUG /D
ZEND_WIN32_FORCE_INLINE /GF /D ZEND_DEBUG=0");
...
// we want msvcrt in the PHP DLL
ADD_FLAG("PHP_LDFLAGS", "/nodefaultlib:libcmt");
-
What will be done with msvcrt dependecy of msvcr80.dll ?
PHP can't be compiled with static linked library, and with dynamic library
is got dependecy of a external dll (Need to install .NET Framework on
machines that will run theses compiled PHP).
How do I compile a stand alone php5ts.dll in VC++ 8.0.
--
Edit bug report at http://bugs.php.net/?id=38288&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38288&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38288&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38288&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38288&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38288&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38288&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38288&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38288&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38288&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38288&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38288&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38288&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38288&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38288&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38288&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38288&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38288&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38288&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38288&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38288&r=mysqlcfg
#38288 [Opn->Bgs]: msvcrt dependency problem in VC++ 8.0
ID: 38288
Updated by: [EMAIL PROTECTED]
Reported By: rafaelhfaria at terra dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Windows XP Pro
PHP Version: 5.1.4
New Comment:
Compiling PHP on Windows alsways requires some Microsoft DLL's. If you
are using VC 6 these DLL's are most likely installed on the system by
default. If you are using VC 7 or VC8 you need to install these DLL's
on the system. This can be done by copying the DLL's to the PHP folder
or by installing/upgrading the .NET framework.
Previous Comments:
[2006-08-01 20:02:37] rafaelhfaria at terra dot com dot br
Description:
I'm compiling PHP 5.4.1 with Microsoft Visual Studio 2005.
But with msvcrt I get an unwanted dependency of "msvcr80.dll". I tried
compile with static link option: "/MT" in place of "/MD" (using
libcmt). But without success...
--- Error Log (with libcmt and without msvcrt):
Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Creating library Release_TS\php5ts.lib and object
Release_TS\php5ts.exp
zend_strtod.obj : error LNK2019: unresolved external symbol __HUGE
referenced in function _zend_strtod
math.obj : error LNK2001: unresolved external symbol __HUGE
php_variables.obj : error LNK2019: unresolved external symbol __environ
referenced in function __php_import_environment_variables
basic_functions.obj : error LNK2001: unresolved external symbol
__environinfo.obj : error LNK2001: unresolved external symbol
__environ
Release_TS\php5ts.dll : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: '"C:\Arquivos de programas\Microsoft Visual
Studio 8\VC\BIN\link.exe"' : return code '0x460'
Stop.
---
Peace of code from "configure.js":
ADD_FLAG("CFLAGS", "/LD /MD /W3 /Ox /D NDebug /D NDEBUG /D
ZEND_WIN32_FORCE_INLINE /GF /D ZEND_DEBUG=0");
...
// we want msvcrt in the PHP DLL
ADD_FLAG("PHP_LDFLAGS", "/nodefaultlib:libcmt");
-
What will be done with msvcrt dependecy of msvcr80.dll ?
PHP can't be compiled with static linked library, and with dynamic
library is got dependecy of a external dll (Need to install .NET
Framework on machines that will run theses compiled PHP).
How do I compile a stand alone php5ts.dll in VC++ 8.0.
--
Edit this bug report at http://bugs.php.net/?id=38288&edit=1
#35793 [Com]: General error: 2050
ID: 35793 Comment by: mass at carlsoft dot net Reported By: deadman_great at mail dot ru Status: No Feedback Bug Type: PDO related Operating System: RH Fedora Core 2 PHP Version: 5CVS-2005-12-25 (snap) Assigned To: Wez New Comment: Can we at least change this error message to be more specific, perhaps suggesting to emulate prepares (as wez @ php . net suggested)? or better yet make the emulation default? Previous Comments: [2006-05-07 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". [2006-05-02 14:53:18] email at steffenweber dot net Upgrading to PHP 5.1.3 and using $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true); fixes the problem for me. [2006-04-30 00:56:35] [EMAIL PROTECTED] Please read this blog entry and see if following the advice there helps: http://netevil.org/node.php?nid=795 (you'll want to upgrade to PHP 5.1.3 or a current snapshot first). [2006-04-17 17:04:04] [EMAIL PROTECTED] You need to change the bug status back to "Open" if the issue still occurs. The bug has been suspended by a cron script because it was still in state "Feedback". I re-opened the bug for you. [2006-04-17 16:56:30] email at steffenweber dot net You must be kidding? :-( 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/35793 -- Edit this bug report at http://bugs.php.net/?id=35793&edit=1
#37368 [Asn->Csd]: Incorrect timestamp returned for strtotime()
ID: 37368
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: Debian sarge
PHP Version: 5.1.4
Assigned To: derick
New Comment:
strtotime("May 1st third Monday") returns false in the latest CVS and I
think the result is correct, since the date is invalid.
Previous Comments:
[2006-05-24 21:41:55] [EMAIL PROTECTED]
Actually, I meant that I expect the output to be (Wed should be changed
to Mon):
Mon, 08 May 2006 00:00:00 -0400
Mon, 15 May 2006 00:00:00 -0400
Mon, 22 May 2006 00:00:00 -0400
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400
[2006-05-24 21:34:23] [EMAIL PROTECTED]
I'm not sure whether this is related, but I found a new issue with
strtotime(). It looks like the words "second" and "third" are not
working correctly.
Reproduce code:
echo date('r', strtotime('May 1st first Monday')) . "\n";
echo date('r', strtotime('May 1st second Monday')) . "\n";
echo date('r', strtotime('May 1st third Monday')) . "\n";
echo date('r', strtotime('May 1st fourth Monday')) . "\n";
echo date('r', strtotime('May 1st fifth Monday')) . "\n";
I expect the output to be:
Mon, 08 May 2006 00:00:00 -0400
Wed, 15 May 2006 00:00:00 -0400
Wed, 22 May 2006 00:00:00 -0400
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400
but the actual output (with PHP 5.1.4) is:
Mon, 08 May 2006 00:00:00 -0400
Wed, 31 Dec 1969 19:00:00 -0500
Wed, 31 Dec 1969 19:00:00 -0500
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400
With PHP 4.4.2, the actual output is:
Tue, 01 May 2001 00:00:00 -0400
Mon, 01 May 2006 00:00:01 -0400
Thu, 01 May 2003 00:00:00 -0400
Sat, 01 May 2004 00:00:00 -0400
Sun, 01 May 2005 00:00:00 -0400
[2006-05-14 17:35:45] [EMAIL PROTECTED]
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
[2006-05-08 17:16:01] [EMAIL PROTECTED]
Description:
When using strtotime() in PHP 5.1.4, it returns an inaccurate
timestamp, but PHP 5.0.4 and 4.4.2 return the correct timestamp.
Reproduce code:
---
php -r 'echo date("r", strtotime("Mon, 08 May 2006 13:06:44 -0400 +30
days"));'
Expected result:
Wed, 07 Jun 2006 13:06:44 -0400
Actual result:
--
Mon, 12 Jun 2006 13:06:44 -0400
--
Edit this bug report at http://bugs.php.net/?id=37368&edit=1
#37349 [Asn->Fbk]: memory corruption within run-tests.php
ID: 37349 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Streams related Operating System: n/a PHP Version: 6CVS-2006-05-07 (CVS) Assigned To: pollita New Comment: Nuno, please check if it's still reproducible with the latest CVS. Thanks. Previous Comments: [2006-06-10 23:31:25] [EMAIL PROTECTED] I've updated the valgrind report, now with ICU 3.5-cvs (contains a fix to a related bug I've reported). Now the report is smaller. IMHO, this is surely a streams problem. as fair as I can see the code isn't calculaing the buffer length correctly when passing that value to u_memchr(). Sara, can you please check this problem? You are the best (if not the only) person who can fix this. [2006-05-27 09:56:19] [EMAIL PROTECTED] I've upgraded ICU to version 3.4.1 and I still get the same problems: http://mega.ist.utl.pt/~ncpl/php6-tidy-valgrind.txt [2006-05-27 09:40:35] [EMAIL PROTECTED] no, Tony, I'm not :) I'll update ICU to check if that is the problem. [2006-05-27 09:33:51] [EMAIL PROTECTED] Nuno, you must be kidding: - [24 May 9:53pm UTC] [EMAIL PROTECTED] <..> I can't reproduce it with the latest CVS. - I said I don't see any valgrind warnings with any of tidy tests, what's the point to refer to your first post? What exactly do you get? [2006-05-26 18:03:44] [EMAIL PROTECTED] Tony: its in my first comment :) You just need to run valgrind on run-tests.php while testing the tidy/tests/020.phpt file. This produces a nice error message: 'BORK TEST', along with a huge valgrind report. (also, the problem might be in ICU. I haven't look further though) 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/37349 -- Edit this bug report at http://bugs.php.net/?id=37349&edit=1
#37120 [Opn->Fbk]: mod_php5 + apache2 + mail() = hung process
ID: 37120 Updated by: [EMAIL PROTECTED] Reported By: brlcad at mac dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: FreeBSD 5.2.1 PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-04-18 23:16:09] brlcad at mac dot com Not sure how helpful this will be, but here are several stack traces while it was hung. Interestingly enough, if I ctrl-c'd in gdb during the hang and continued, the page would unhang and return a mail() failure. (gdb) run -X -f /usr/local/etc/apache2/httpd.conf (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... ^C Program received signal SIGINT, Interrupt. 0x283d92af in poll () from /lib/libc.so.5 (gdb) where #0 0x283d92af in poll () from /lib/libc.so.5 #1 0x2847ba51 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 #2 0x2847b445 in _thread_kern_scheduler () from /usr/ lib/libc_r.so.5 (gdb) c Continuing. [ NOTE: HERE THE PAGE UNHUNG ] ^C Program received signal SIGINT, Interrupt. 0x283d92af in poll () from /lib/libc.so.5 (gdb) where #0 0x283d92af in poll () from /lib/libc.so.5 #1 0x2835977e in apr_poll () from /usr/local/lib/ apache2/libapr-0.so.9 #2 0x28359f32 in apr_wait_for_io_or_timeout () from / usr/local/lib/apache2/libapr-0.so.9 #3 0x2835052a in apr_socket_recv () from /usr/local/ lib/apache2/libapr-0.so.9 #4 0x28350e9d in apr_recv () from /usr/local/lib/ apache2/libapr-0.so.9 #5 0x080705f0 in ap_lingering_close () #6 0x080640ab in child_main () #7 0x0806417c in make_child () #8 0x080642c2 in startup_children () #9 0x080646c2 in ap_mpm_run () #10 0x0806b7d3 in main () #11 0x0805cfd2 in _start () (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x283d92af in poll () from /lib/libc.so.5 (gdb) where #0 0x283d92af in poll () from /lib/libc.so.5 #1 0x2847ba51 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 #2 0x2847b445 in _thread_kern_scheduler () from /usr/ lib/libc_r.so.5 (gdb) c Continuing. [ NOTE: HERE THE PAGE UNHUNG ] ^C Program received signal SIGINT, Interrupt. 0x283d92af in poll () from /lib/libc.so.5 (gdb) where #0 0x283d92af in poll () from /lib/libc.so.5 #1 0x2835977e in apr_poll () from /usr/local/lib/ apache2/libapr-0.so.9 #2 0x28359f32 in apr_wait_for_io_or_timeout () from / usr/local/lib/apache2/libapr-0.so.9 #3 0x2835052a in apr_socket_recv () from /usr/local/ lib/apache2/libapr-0.so.9 #4 0x28350e9d in apr_recv () from /usr/local/lib/ apache2/libapr-0.so.9 #5 0x080705f0 in ap_lingering_close () #6 0x080640ab in child_main () #7 0x0806417c in make_child () #8 0x080642c2 in startup_children () #9 0x080646c2 in ap_mpm_run () #10 0x0806b7d3 in main () #11 0x0805cfd2 in _start () (gdb) quit [2006-04-18 22:47:43] brlcad at mac dot com I'll give that a try, though this is on a very heavy loaded production machine (hundreds of web hits per minute) -- I'll need to wait for the load to settle a little, hopefully later tonight. That said, in the meantime I thought I'd share some more insight testing. I fully replaced sendmail with qmail to make sure it wasn't something particular with the configuration of sendmail. Again, the machine has no problems sending e-mail on the command line or with mail clients, but mod_php5 hangs on the mail() call. Curiously enough, before installing qmail if I made the clientmqueue dir unreadable so that sendmail reported an error/failure, the mail() call does return immediately (reporting a failure return code) so the hanging does seem to be specific to when the mail 'should' go through correctly. [2006-04-18 21:30:49] [EMAIL PROTECTED] Please try to reproduce it with only one Apache process (httpd -X) and if yes - get a GDB backtrace of the place where it freezes. [2006-04-18 15:12:04] brlcad at mac dot com When I attempt to use the sendmail binary directly, I have no problems: $ /usr/local/sbin/sendmail -t -i -v -X /tmp/sendmail.log [EMAIL PROTECTED] To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: this is a test... testing. [CTRL-d] The message is successfully delivered both with and without the above shown header provided. Looking at the -X debug logs, the difference running the command directly versus what I'm seeing when php runs is a lack of the EOF, shown below as follows: >From
#36647 [Asn->Csd]: __get and foreach / Segfaults
ID: 36647 Updated by: [EMAIL PROTECTED] Reported By: pumuckel at metropolis dot de -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5CVS-2006-03-07 (snap) Assigned To: dmitry New Comment: Not reproducible with 5.2-CVS. Previous Comments: [2006-03-23 01:16:58] judas dot iscariote at gmail dot com This test also leaks memory.. /local/local/bodegon/php-debug/Zend/zend_hash.c(764) : Freeing 0x00A1D3A0 (71 bytes), script=foreach.php /local/local/bodegon/php-debug/Zend/zend_hash.c(383) : Actual location (location was relayed) Last leak repeated 2 times [Wed Mar 22 20:16:04 2006] Script: 'foreach.php' /local/local/bodegon/php-debug/Zend/zend_variables.c(133) : Freeing 0x00A1D090 (64 bytes), script=foreach.php /local/local/bodegon/php-debug/Zend/zend_hash.c(169) : Actual location (location was relayed) [Wed Mar 22 20:16:04 2006] Script: 'foreach.php' /local/local/bodegon/php-debug/Zend/zend_variables.h(45) : Freeing 0x00A1CFF0 (72 bytes), script=foreach.php /local/local/bodegon/php-debug/Zend/zend_variables.c(132) : Actual location (location was relayed) [Wed Mar 22 20:16:04 2006] Script: 'foreach.php' /local/local/bodegon/php-debug/Zend/zend_vm_execute.h(7460) : Freeing 0x00A1CAA0 (24 bytes), script=foreach.php [Wed Mar 22 20:16:04 2006] Script: 'foreach.php' /local/local/bodegon/php-debug/Zend/zend_compile.c(3208) : Freeing 0x00A139D0 (24 bytes), script=foreach.php Last leak repeated 2 times === Total 9 memory leaks detected === [2006-03-07 17:56:40] [EMAIL PROTECTED] Dmitry, please look into it. [2006-03-07 17:50:29] pumuckel at metropolis dot de Operating System: Gentoo Linux and SuSE 8.1 PHP 5.1.3-dev (cli) (built: Mar 7 2006 15:07:07) PHP 5.0.5 (cli) (built: Feb 2 2006 11:35:32) and appropriate apache2 modules. gdb backtrace of 5.1.3 php module of our application: (gdb) backtrace #0 _zend_hash_add_or_update (ht=0x87c652c, arKey=0xb7aafbf5 "args", nKeyLength=5, pData=0xbfffb16c, nDataSize=4, pDest=0x0, flag=1) at /usr/local/php5.1-200603071330/Zend/zend_hash.c:213 #1 0xb78b9124 in add_assoc_zval_ex (arg=0x0, key=0xb7aafbf5 "args", key_len=5, value=0x87c607c) at zend_hash.h:331 #2 0xb78c5581 in zend_fetch_debug_backtrace (return_value=0x87c607c, skip_last=1, provide_object=1) at /usr/local/php5.1-200603071330/Zend/zend_builtin_functions.c:1938 #3 0xb78d1b80 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffb4a0) at zend_vm_execute.h:200 #4 0xb78d14dc in execute (op_array=0x8442a98) at zend_vm_execute.h:92 #5 0xb78d1760 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffb790) at zend_vm_execute.h:234 #6 0xb78d14dc in execute (op_array=0x8646c84) at zend_vm_execute.h:92 #7 0xb790c0f7 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0xbfffbc50) at zend_vm_execute.h:19441 #8 0xb78d14dc in execute (op_array=0x873a45c) at zend_vm_execute.h:92 #9 0xb78d1760 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffbfa0) at zend_vm_execute.h:234 #10 0xb78d14dc in execute (op_array=0x84b0f94) at zend_vm_execute.h:92 #11 0xb78d1760 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffc3b0) at zend_vm_execute.h:234 #12 0xb78d14dc in execute (op_array=0x870b194) at zend_vm_execute.h:92 #13 0xb78d1760 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcb20) at zend_vm_execute.h:234 #14 0xb78d14dc in execute (op_array=0x85d42fc) at zend_vm_execute.h:92 #15 0xb78d1760 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcca0) at zend_vm_execute.h:234 #16 0xb78d14dc in execute (op_array=0x83ffb94) at zend_vm_execute.h:92 #17 0xb78b6660 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/php5.1-200603071330/Zend/zend.c:1109 #18 0xb787a21d in php_execute_script (primary_file=0xbfffeff0) at /usr/local/php5.1-200603071330/main/main.c:1719 #19 0xb7926d5a in php_handler (r=0x84c2920) at /usr/local/php5.1-200603071330/sapi/apache2handler/sapi_apache2.c:584 #20 0x08068a45 in ap_run_handler (r=0x84c2920) at config.c:152 #21 0x08069040 in ap_invoke_handler (r=0x84c2920) at config.c:364 #22 0x0806593a in ap_process_request (r=0x84c2920) at http_request.c:249 #23 0x08060dcd in ap_process_http_connection (c=0x83c01e8) at http_core.c:251 #24 0x08072925 in ap_run_process_connection (c=0x83c01e8) at connection.c:43 #25 0x08067044 in child_main (child_num_arg=0) at prefork.c:610 #26 0x08067197 in make_child (s=0x0, slot=0) at prefork.c:704 #27 0x08067429 in perform_idle_server_maintenance (p=0x80a2e28) at prefork.c:839 #28 0x08067b15 in ap_mpm_run (_pconf=0x0, plog=0x80cced0, s=0x0) at prefork.c:1040 #29 0x0806e0ad in main (argc=5, argv=0xb434) at main.c:618 gdb bt of 5.0.5 php module looks a lot differen
#36571 [Asn->Csd]: __set() affects outer variable when overloading with "[]=" and "{}="
ID: 36571
Updated by: [EMAIL PROTECTED]
Reported By: cid73 at 163 dot com
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.1.3RC3
Assigned To: dmitry
New Comment:
Not reproducible with 5.2-CVS.
Previous Comments:
[2006-04-12 09:59:05] [EMAIL PROTECTED]
One more overloading bug.
It is unfixable at this moment :(
[2006-04-11 11:37:18] [EMAIL PROTECTED]
Dmitry, this does not look right to me.
[2006-03-01 14:55:50] cid73 at 163 dot com
Description:
I'm not sure if there are inner operaters named "[]=" or "{}=", but it
really goes wrong when overloading such operations.
Here's some demo code.
Reproduce code:
---
class Setter
{
private $attributes;
public function __construct($attributes) {
$this->attributes = $attributes; }
private function __set($var, $value) {
$this->attributes[$var] = $value; }
private function __get($var) {
if ( isset($this->attributes[$var]) ) {
return $this->attributes[$var]; }
else {
return null; }}
}
$a = array('a' => array('a', 'b', 'c'), 'b' => 'Hello');
$o = new Setter($a);
$o->a[0] = 'A';
$o->a[] = 'd';
$o->b{0} = 'h';
print_r($a); // gotta check $a, $o is good
/* ouputs:
Array
(
[a] => Array
(
[0] => A
[1] => b
[2] => c
[3] => d
)
[b] => hello
)
*/
Expected result:
$a is unchangeable at the moment
Actual result:
--
$a was modified
--
Edit this bug report at http://bugs.php.net/?id=36571&edit=1
#36567 [Asn->Csd]: $obj->arr[] with __set/__get cause data corrupted without any warning
ID: 36567
Updated by: [EMAIL PROTECTED]
Reported By: xuefer at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: gentoo
PHP Version: 5CVS-2006-03-01 (CVS)
Assigned To: dmitry
New Comment:
Not reproducible with 5.2-CVS.
Previous Comments:
[2006-03-02 15:43:11] [EMAIL PROTECTED]
Dmitry, could you please look into this?
[2006-03-01 12:13:07] xuefer at gmail dot com
Description:
yeah, i know using "$obj->arr[]" with __set/__get, the result is
undefined. but shouldn't it be denied? because it's causing really bad
side effect now... and hard to debug if there's no warning.
it's hard to know the instance $obj will be used as $obj->arr[] = '';
else where, if the project is big enough, while u implement __set/__get
for classes happily
relatived bug:
http://bugs.php.net/bug.php?id=33941
Reproduce code:
---
vars = $vars;
}
public function __get($key)
{
echo "get $key\n";
return $this->vars[$key];
}
public function __set($key, $value)
{
echo "set $key to $value \n";
$this->vars[$key] = $value;
}
}
$vars = array('test' => array(0 => ""));
$obj = new test($vars);
$obj->test[0] = 'modified';
var_dump($vars);
?>
to reproduce the leak in http://bugs.php.net/bug.php?id=33941
vars = $vars;
}
public function __get($key)
{
return $this->vars[$key];
}
}
$vars = array('test' => array(0 => ""));
$obj = new test($vars);
$obj->undefined[0] = 'modified';
?>
Notice: Undefined index: undefined in /tmp/test.php on line 12
[Wed Mar 1 19:08:25 2006] Script: './/test.php'
/usr/src/php5/Zend/zend_variables.h(45) : Freeing 0x08765E2C (9
bytes), script=.//test.php
/usr/src/php5/Zend/zend_variables.c(120) : Actual location (location
was relayed)
[Wed Mar 1 19:08:25 2006] Script: './/test.php'
/usr/src/php5/Zend/zend_execute.c(1020) : Freeing 0x0877BACC (35
bytes), script=.//test.php
/usr/src/php5/Zend/zend_hash.c(383) : Actual location (location was
relayed)
[Wed Mar 1 19:08:25 2006] Script: './/test.php'
/usr/src/php5/Zend/zend_execute.c(1076) : Freeing 0x0877BA7C (32
bytes), script=.//test.php
/usr/src/php5/Zend/zend_hash.c(169) : Actual location (location was
relayed)
Last leak repeated 1 time
[Wed Mar 1 19:08:25 2006] Script: './/test.php'
/usr/src/php5/Zend/zend_execute.c(842) : Freeing 0x0877B9DC (16
bytes), script=.//test.php
[Wed Mar 1 19:08:25 2006] Script: './/test.php'
/usr/src/php5/Zend/zend_execute.c(1072) : Freeing 0x0877B88C (16
bytes), script=.//test.php
Expected result:
output
array(1) {
["test"]=>
array(1) {
[0]=>
string(0) ""
}
}
and just don't call __get/__set, raising a warning
Actual result:
--
get test
array(1) {
["test"]=>
array(1) {
[0]=>
string(8) "modified"
}
}
--
Edit this bug report at http://bugs.php.net/?id=36567&edit=1
#36484 [Asn->Csd]: Overloading bug
ID: 36484
Updated by: [EMAIL PROTECTED]
Reported By: dave at dgx dot cz
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: Windows XP
PHP Version: 5.1.2
Assigned To: dmitry
New Comment:
Not reproducible with 5.2-CVS.
Previous Comments:
[2006-02-22 02:06:00] dave at dgx dot cz
Description:
Overloading results in unexpectable behaviour when using two arrays in
overloaded object.
Reproduce code:
---
// basic overloading usage
class Test {
private
$vars = array(),
$vars2 = array();
function __get($name)
{
return $this->vars[$name];
}
function __set($name, $value)
{
$this->vars[$name] = $value;
}
// initialize new variable
function add($name, $value)
{
$this->vars[$name] = $value;
// this second array is not used anymore - but it causes error
$this->vars2[$name] = $value;
}
}
$obj = new Test();
$obj->add('order', array(0, 1, 2));
// first test
$obj->order[2] = $obj->order[1];
print_r($obj);
// second test
$obj->order[0] = 99;
print_r($obj);
Expected result:
// first test
Test Object
(
[vars:private] => Array
(
[order] => Array
(
[0] => 0
[1] => 1
[2] => 1
)
)
[vars2:private] => Array
(
[order] => Array
(
[0] => 0
[1] => 1
[2] => 2
)
)
// second test
Test Object
(
[vars:private] => Array
(
[order] => Array
(
[0] => 99
[1] => 1
[2] => 1
)
)
[vars2:private] => Array
(
[order] => Array
(
[0] => 0
[1] => 1
[2] => 2
)
)
Actual result:
--
// first test
Test Object
(
[vars:private] => Array
(
[order] => Array
(
[0] => 0
[1] => 1
[2] => 2
)
)
[vars2:private] => Array
(
[order] => Array
(
[0] => 0
[1] => 1
[2] => 2
)
)
)
// second test
Test Object
(
[vars:private] => Array
(
[order] => Array
(
[0] => 99
[1] => 1
[2] => 2
)
)
[vars2:private] => Array
(
[order] => Array
(
[0] => 99
[1] => 1
[2] => 2
)
)
)
--
Edit this bug report at http://bugs.php.net/?id=36484&edit=1
#3131 [Opn->WFx]: Errors while connecting Oracle database
ID: 3131 Updated by: [EMAIL PROTECTED] Reported By: luvan at iname dot com -Status: Open +Status: Wont fix Bug Type: OCI8 related Operating System: Linux 2.2.5 PHP Version: 3.0.12 Previous Comments: [2005-03-30 09:03:06] [EMAIL PROTECTED] We are sorry, but we can not support PHP 3 related problems anymore. Momentum is gathering for PHP 5, and we think supporting PHP 3 will lead to a waste of resources which we want to put into getting PHP 5 ready. Of course PHP 4 will continue to be supported for the forseeable future. [2000-01-07 04:57:31] luvan at iname dot com We are using Oracle 8.0.5 and Apache 1.3.9 and we have following problems: 1. Ocassional loss of persistent connection to Oracle database. Oracle returns ORA-01041 or ORA-03113. 2. When using non-persistent connect, OCIlogon fails (again occasionally) with ORA-12154, IMHO as a consequence of error ORA-12545. We found out that after the first appearance of the error this webserver process (one of Apache's sons) is not able to connect anymore and only possibility to refresh the application is to kill it. There is the file sqlnet.log in working directory with following messages: -- Fatal NI connect error 12545, connecting to: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(COMMUNITY=tcp_hrouda_pre.world)(PROTOCOL=TCP)(Host=wwwcall)(Port=1 521)))(CONNECT_DATA=(SID=CCP)(CID=(PROGRAM=)(HOST=vl11823)(USER=nobody VERSION INFORMATION: TNS for Linux: Version 8.0.5.0.0 - Production TCP/IP NT Protocol Adapter for Linux: Version 8.0.5.0.0 - Production Time: 06-JAN-00 16:01:03 Tracing not turned on. Tns error struct: nr err code: 12206 TNS-12206: TNS:received a TNS error during navigation ns main err code: 12545 TNS-12545: Connect failed because target host or object does not exist ns secondary err code: 12560 nt main err code: 515 TNS-00515: Connect failed because target host or object does not exist nt secondary err code: 111 nt OS err code: 0 nt OS err code: 0 -- The database server is on the same machine as the webserver and Oracle vars are set in Apache's environment. We mean that both problems (1. and 2.) have the same cause (somewhere in PHP, Apache or Linux ??) We found similar problems in: - bug #2487 - http://www.weberdev.com/forum/read.php3?num=1&id=854&thread=854&; Appropriate files: http://mujweb.cz/www/luvan/sqlnet.log http://mujweb.cz/www/luvan/tnsnames_ora.txt (appr. part of tnsnames.ora) http://mujweb.cz/www/luvan/set-out.txt (output of set called via PHP) http://mujweb.cz/www/luvan/oci8.php (OCI itf functions from the appl) Many thanks for helping us -- Edit this bug report at http://bugs.php.net/?id=3131&edit=1
#36995 [Asn->Opn]: when imagepng() and friends fail there is no way to know why
ID: 36995 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Open Bug Type: GD related Operating System: Linux PHP Version: 5CVS-2006-04-06 (CVS) Assigned To: pajoye New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Tony requests, Tony adds. Previous Comments: [2006-04-06 13:06:25] [EMAIL PROTECTED] Description: imagepng()/imagegif()/imagejpeg() function do not report the exact reason why they failed to write to the file. This makes it difficult to debug, as you know it fails, but it doesn't say why. Reproduce code: --- Expected result: Warning: imagepng(): Unable to open '/root/test.jpg' for writing : Permission denied in .. on line .. Actual result: -- Warning: imagepng(): Unable to open '/root/test.jpg' for writing in .. on line .. -- Edit this bug report at http://bugs.php.net/?id=36995&edit=1
#35163 [Asn->Csd]: Array elements can lose references.
ID: 35163
Updated by: [EMAIL PROTECTED]
Reported By: averagomez at hotmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Arrays related
Operating System: *
PHP Version: 5CVS-2005-11-09 (cvs)
Assigned To: dmitry
New Comment:
Not reproducible with 5.2-CVS.
Previous Comments:
[2005-11-16 14:52:19] [EMAIL PROTECTED]
5.1 is effected too.
The problem is in "$a[0][] =& $a[0];" operator, that creates copy of
$a[0] during fetching lvalue because $a[0] is not a reference and after
fetching rvalue it has refcount > 1.
[2005-11-09 05:45:44] averagomez at hotmail dot com
Description:
Sorry I have a very bad english but I think the 'Reproduce code' is
self-describing.
Reproduce code:
---
// -- This work OK:
$a = array('A', & $a, & $a);
$a[1][0] = 'B';
echo $a[0]; // OK : Show 'B'
// -- But this don't work:
$a = array('A');
$a[1] = & $a;
$a[2] = & $a;
$a[1][0] = 'B';
echo $a[0]; // Wrong: Show 'A'
Expected result:
BB
Actual result:
--
BA
--
Edit this bug report at http://bugs.php.net/?id=35163&edit=1
#36995 [Opn->Csd]: when imagepng() and friends fail there is no way to know why
ID: 36995 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Linux PHP Version: 5CVS-2006-04-06 (CVS) Assigned To: pajoye Previous Comments: [2006-08-01 22:42:49] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Tony requests, Tony adds. [2006-04-06 13:06:25] [EMAIL PROTECTED] Description: imagepng()/imagegif()/imagejpeg() function do not report the exact reason why they failed to write to the file. This makes it difficult to debug, as you know it fails, but it doesn't say why. Reproduce code: --- Expected result: Warning: imagepng(): Unable to open '/root/test.jpg' for writing : Permission denied in .. on line .. Actual result: -- Warning: imagepng(): Unable to open '/root/test.jpg' for writing in .. on line .. -- Edit this bug report at http://bugs.php.net/?id=36995&edit=1
#33931 [Opn->Csd]: __get and __set don't handle arrays correctly
ID: 33931
Updated by: [EMAIL PROTECTED]
Reported By: wkonkel at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-08-19
Assigned To: dmitry
New Comment:
Not reproducible with 5.2-CVS.
Previous Comments:
[2006-07-27 13:19:18] wkonkel at gmail dot com
This is still a problem.
[2006-07-26 09:39:19] christianl at ossafrica dot com
I have the same problem on Apache 2.0.55, PHP 5.1.4. I'm trying to
access object properties with __set and __get. In my application its
difficult to see whats causing it, but this seems to concur with some
of the behaviour I'm getting. (Array values being set to 0). On
occasion the page is output to download instead of parsed and I get a
segmentation fault in Apache. The reproduce code outputs the above
mentioned actual result.
[2006-01-10 08:46:28] matt at matttoddphoto dot com
I have had the same problem. This is terrible in the sense
that I'd love to have this work, yet it doesn't. Shame.
When I have:
class Response {
private $collection;
public function __set($name, $value) {
$this->collection[$name] = $value;
}
public function __get($name) {
return $this->collection[$name];
}
}
The following does not assign anything but empty array()s
into the private $collection property.
For instance (which is called from within another class,
hence the $this reference):
foreach($posts as $post) {
$this->response->posts[$post['id']] = $post;
}
Now,
print_r($this->response->posts);
will output:
Array();
N.B. -- I had not noticed the bizarre activity with the
properties reappearing in sequence immediately. In fact, I
couldn't explain the bizarre behavior for two separate,
nearly-identical loops like this one resulted in all of the
data in the final of the two. Now I understand why it was
combining the two. Bizarre indeed!
[2005-09-24 01:00:03] 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".
[2005-09-17 00:48:23] [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
I'm unable to replicate it anymore.
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/33931
--
Edit this bug report at http://bugs.php.net/?id=33931&edit=1
#38289 [NEW]: session_decode()/$_SESSION problem
From: [EMAIL PROTECTED] Operating system: PHP version: 5.1.4 PHP Bug Type: Session related Bug description: session_decode()/$_SESSION problem Description: session_decode() core dumps if $_SESSION is set to null before calling it. Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=38289&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38289&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38289&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38289&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38289&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38289&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38289&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38289&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38289&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38289&r=support Expected behavior:http://bugs.php.net/fix.php?id=38289&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38289&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38289&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38289&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38289&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38289&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38289&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38289&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38289&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38289&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38289&r=mysqlcfg
#38122 [Opn]: Misleading error message for recursive use of __get()
ID: 38122
User updated by: toomuchphp-phpbugs at yahoo dot com
Reported By: toomuchphp-phpbugs at yahoo dot com
Status: Open
-Bug Type:Feature/Change Request
+Bug Type:Class/Object related
-PHP Version: 5.1.4
+PHP Version: 5.2.0RC1
New Comment:
Also occurs in PHP-5.2.0RC1.
Previous Comments:
[2006-07-17 08:14:27] toomuchphp-phpbugs at yahoo dot com
Description:
Recursive use of __get() results in the misleading error message
"Notice: Undefined property: someClass::$foo in file.php". It appears
at first as though __get() is not being called for some properties and
there is no apparent reason why, when the problem is really accidental
recursion. PHP correctly detects the recursion and aborts __get(), but
the error gives no indication of the recursion problem and it can be
very difficult to figure out why __get() is not being called.
I can provide a fix for zend_object_handlers.c, but it really is just a
60-second change to capture the recursiveness error and output an
alternative error message.
Reproduce code:
---
class test {
function __get($var) {
return $this->$var;
}
}
$obj = new test;
echo $obj->foo;
Expected result:
Warning: Recursive use of __get() while accessing test::$foo; cannot
read property recursive::$foo in on line x
Actual result:
--
Notice: Undefined property: test::$foo in on line x
--
Edit this bug report at http://bugs.php.net/?id=38122&edit=1
#38290 [NEW]: configure script ignores --without-cdb
From: tietew at tietew dot net Operating system: Linux PHP version: 5.1.4 PHP Bug Type: *Configuration Issues Bug description: configure script ignores --without-cdb Description: I want to compile PHP with dba but I don't want to include cdb support in order to resolve libcdb confliction problem temporarily. I passed "--enable-dba --without-cdb" to configure script but the script have ignored --without-cdb. Reproduce code: --- ./configure --enable-dba --with-gdbm --with-db4 --without-cdb Expected result: PHP is compiled with dba but without cdb support. Actual result: -- PHP is compiled with cdb support. -- Edit bug report at http://bugs.php.net/?id=38290&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38290&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38290&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38290&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38290&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38290&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38290&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38290&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38290&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38290&r=support Expected behavior:http://bugs.php.net/fix.php?id=38290&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38290&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38290&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38290&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38290&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38290&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38290&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38290&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38290&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38290&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38290&r=mysqlcfg
