#48866 [Com]: ldap.conf TLS_REQCERT directive fails for ldaps
ID: 48866
Comment by: mahida at usq dot edu dot au
Reported By: dev at lechat dot org
Status: Feedback
Bug Type: LDAP related
Operating System: windows server 2003 R2 SE SP2
PHP Version: 5.3.0
New Comment:
PHP 5.1.6,Red Hat 4.1.2-44,httpd-2.2.3-22.el5, mysql-5.0.45-7.el5
We have the same problem for above. We manually copied the LDAP server
certificate and it worked. But the LDAPS bind is so unstable. Sometime
it binds and sometime it fails.
Standard LDAP connection works as expected.
Previous Comments:
[2009-08-07 06:30:01] mahida at usq dot edu dot au
PHP 5.1.6,Red Hat 4.1.2-44,httpd-2.2.3-22.el5, mysql-5.0.45-7.el5
We have the same problem for above. We manually copied the LDAP server
certificate and it worked. But the LDAPS bind is so unstable. Sometime
it binds and sometime it fails.
Standard LDAP connection works as expected.
[2009-08-05 21:59:26] j...@php.net
Does this happen also with PHP 5.2.10 ?
[2009-07-09 09:35:06] dev at lechat dot org
Description:
Dealing with a secure ldap connection :
Since php 5.3, the
'TLS_REQCERT never' (means do not check certificate validity, and
process the request anymore)
directive in C:\OpenLDAP\sysconf\ldap.conf are not applied when trying
to bind an ldapS server that emit a certificate with an invalid CA.
The result is that the ldapS bind fails because php refuse the
certificate.
By using a filMonitor program, I saw that since php 5.3 php_ldap.dll,
the ldap conf file is now 'c:\ldap.conf' rather than
C:\OpenLDAP\sysconf\ldap.conf. I tried to put directive in this file
too. I can see that the file is open and read, but the directive
'TLS_REQCERT never' is not applied. Bind fails.
On the same server this is perfectly working with php < 5.3 (until
5.2.9-1 as fas as I know).
Note that standard ldap connection works as expected with 5.3
Reproduce code:
---
$ldapConnect = ldap_connect('ldaps://ldaps.myserver.com:3269');
ldap_set_option($ldapConnect, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ldapConnect, LDAP_OPT_REFERRALS, 0);
$ldapBind = ldap_bind($ldapConnect, $username,$password);
$filter="(| (employeeid=$user)(name=$user)(cn=$user)
(userprincipalname=$u...@mydomain) ) ";
$ldapSearch = ldap_search($ldapConnect, $baseDn, $filter);
$ldapEntries = ldap_get_entries($ldapConnect, $ldapSearch);
ldap_free_result($ldapSearch);
ldap_unbind($ldapConnect);
Expected result:
ldap_get_entries returns ldap entries that match whith the filter, as
expected.
Actual result:
--
None, cannot bind.
--
Edit this bug report at http://bugs.php.net/?id=48866&edit=1
#48866 [Com]: ldap.conf TLS_REQCERT directive fails for ldaps
ID: 48866
Comment by: mahida at usq dot edu dot au
Reported By: dev at lechat dot org
Status: Feedback
Bug Type: LDAP related
Operating System: windows server 2003 R2 SE SP2
PHP Version: 5.3.0
New Comment:
PHP 5.1.6,Red Hat 4.1.2-44,httpd-2.2.3-22.el5, mysql-5.0.45-7.el5
We have the same problem for above. We manually copied the LDAP server
certificate and it worked. But the LDAPS bind is so unstable. Sometime
it binds and sometime it fails.
Standard LDAP connection works as expected.
Previous Comments:
[2009-08-05 21:59:26] j...@php.net
Does this happen also with PHP 5.2.10 ?
[2009-07-09 09:35:06] dev at lechat dot org
Description:
Dealing with a secure ldap connection :
Since php 5.3, the
'TLS_REQCERT never' (means do not check certificate validity, and
process the request anymore)
directive in C:\OpenLDAP\sysconf\ldap.conf are not applied when trying
to bind an ldapS server that emit a certificate with an invalid CA.
The result is that the ldapS bind fails because php refuse the
certificate.
By using a filMonitor program, I saw that since php 5.3 php_ldap.dll,
the ldap conf file is now 'c:\ldap.conf' rather than
C:\OpenLDAP\sysconf\ldap.conf. I tried to put directive in this file
too. I can see that the file is open and read, but the directive
'TLS_REQCERT never' is not applied. Bind fails.
On the same server this is perfectly working with php < 5.3 (until
5.2.9-1 as fas as I know).
Note that standard ldap connection works as expected with 5.3
Reproduce code:
---
$ldapConnect = ldap_connect('ldaps://ldaps.myserver.com:3269');
ldap_set_option($ldapConnect, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ldapConnect, LDAP_OPT_REFERRALS, 0);
$ldapBind = ldap_bind($ldapConnect, $username,$password);
$filter="(| (employeeid=$user)(name=$user)(cn=$user)
(userprincipalname=$u...@mydomain) ) ";
$ldapSearch = ldap_search($ldapConnect, $baseDn, $filter);
$ldapEntries = ldap_get_entries($ldapConnect, $ldapSearch);
ldap_free_result($ldapSearch);
ldap_unbind($ldapConnect);
Expected result:
ldap_get_entries returns ldap entries that match whith the filter, as
expected.
Actual result:
--
None, cannot bind.
--
Edit this bug report at http://bugs.php.net/?id=48866&edit=1
#49187 [Opn]: Misbehaving function : intval ()
ID: 49187
User updated by: belanger dot b at gmail dot com
Reported By: belanger dot b at gmail dot com
Status: Open
Bug Type: *Math Functions
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Tested it with all values from previously rejected or ignored similar
bug submissions (code and execution here) :
http://www.benlg.com/test.php
P.S.: intval('9.95'*100) == intval(9.95*100) == 994
Previous Comments:
[2009-08-07 05:20:11] belanger dot b at gmail dot com
Description:
intval is not returning the correct value for '995'
echo number_format('9.95'*100,0,'',''); // output 995
echo intval('9.95'*100); // output 994
Sorry but the most up to date server at my disposition is version
5.2.5
POSSIBLY RELATED REFUSED BUGS...
found by me :
http://bugs.php.net/bug.php?id=1960 (set to closed)
found by system :
http://bugs.php.net/bug.php?id=37554 (set to bogus)
http://bugs.php.net/bug.php?id=39900 (set to bogus)
Reproduce code:
---
echo number_format('9.95'*100,0,'','')
.' and '. number_format('1.16'*100,0,'','')
."\n". intval('9.95'*100);
.' and '. intval('1.16'*100);
Expected result:
995 and 116
995 and 116
Actual result:
--
995 and 116
994 and 115
--
Edit this bug report at http://bugs.php.net/?id=49187&edit=1
#49187 [NEW]: Misbehaving function : intval ()
From: belanger dot b at gmail dot com
Operating system: Linux
PHP version: 5.2.10
PHP Bug Type: *Math Functions
Bug description: Misbehaving function : intval ()
Description:
intval is not returning the correct value for '995'
echo number_format('9.95'*100,0,'',''); // output 995
echo intval('9.95'*100); // output 994
Sorry but the most up to date server at my disposition is version 5.2.5
POSSIBLY RELATED REFUSED BUGS...
found by me :
http://bugs.php.net/bug.php?id=1960 (set to closed)
found by system :
http://bugs.php.net/bug.php?id=37554 (set to bogus)
http://bugs.php.net/bug.php?id=39900 (set to bogus)
Reproduce code:
---
echo number_format('9.95'*100,0,'','')
.' and '. number_format('1.16'*100,0,'','')
."\n". intval('9.95'*100);
.' and '. intval('1.16'*100);
Expected result:
995 and 116
995 and 116
Actual result:
--
995 and 116
994 and 115
--
Edit bug report at http://bugs.php.net/?id=49187&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49187&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49187&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49187&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49187&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49187&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49187&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49187&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49187&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49187&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49187&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49187&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49187&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49187&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49187&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49187&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49187&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49187&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49187&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49187&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49187&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49187&r=mysqlcfg
#49186 [NEW]: apache2.2 crashed when set error_log
From: zjjhzx at gmail dot com Operating system: winxp sp3 PHP version: 5.2.10 PHP Bug Type: Apache2 related Bug description: apache2.2 crashed when set error_log Description: I'm using apache 2.2.11. The php is configured as Apache Module. When I set error_log in php.ini and restart Apache, cpu's usage reachs 50%. The file is created successfully. But windows throws an error report soon said found error in php5ts.dll. ´íÎóÓ¦ÓóÌÐò httpd.exe£¬°æ±¾ 2.2.11.0£¬´íÎóÄ£¿é php5ts.dll£¬°æ±¾ 5.2.10.10£¬´íÎóµØÖ· 0x000f2f0b¡£ Reproduce code: --- error_log = "C:/php_errors.log" -- Edit bug report at http://bugs.php.net/?id=49186&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49186&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49186&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49186&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49186&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49186&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49186&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49186&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49186&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49186&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49186&r=support Expected behavior: http://bugs.php.net/fix.php?id=49186&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49186&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49186&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49186&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49186&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49186&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49186&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49186&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49186&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49186&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49186&r=mysqlcfg
#47761 [Opn]: Since 5.2.9 SoapClient no longer attempts Basic auth to retrieve a WSDL file
ID: 47761 User updated by: marques at displague dot com Reported By: marques at displague dot com Status: Open Bug Type: SOAP related Operating System: * PHP Version: 5.2.9 New Comment: One scenario, you are making your own SOAP Server service. It is more difficult to write a digest auth server than it is to write a basic auth server. Again, consider that PHP web requests are all made as HTTP/1.0 because Chunk decoding is not handled properly (or at all) and so Digest, which is HTTP/1.1 specific is technically not an option without a good deal of custom coding. Aside from that, I imagine there are just some HTTP/1.0 or Basic only servers out there. Previous Comments: [2009-08-06 22:02:12] sriram dot natarajan at gmail dot com why is there still a need to support basic authentication ? can u kindly explain that scenario ? [2009-03-24 13:53:48] marques at displague dot com Description: Since 5.2.9, SoapClient no longer attempts HTTP Basic authentication to retrieve a wsdl file. Prior to this version Basic was attempted and Digest was not. Digest should also be attempted but that is a matter for another bug. The SoapClient option 'authentication' has no effect on wsdl retrieval. A work-around is to fetch the WSDL file manually or via PHP commands within the SOAP code, but that method can be cumbersome because digest auth code has to be written from scratch and Bug #47759 (chunk encoding) can get in the way. -- Edit this bug report at http://bugs.php.net/?id=47761&edit=1
#49185 [Opn->WFx]: Feature Request: Global date/time
ID: 49185 Updated by: ras...@php.net Reported By: ryan14 at mail dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: Windows/Linux PHP Version: 5.3.0 New Comment: You are underestimating how complicated that problem is. The easiest and most accurate way to do this is to simply have users tell you which timezone they are in and set that in their profile. If you want to do it automatically you need a huge geoip database to get the ip to a lat/lon and then once you have that you need a huge geo database to turn the lat/lon into a timezone. We can't possible include these with PHP, and they would be out of date in weeks. What we do provide, however, is the base functionality to make it easy to connect to services that have these databases. For example, we have a geoip extension in pecl. See http://pecl.php.net/geoip and the example of it in action here: http://geoip.pidgets.com Once you have the lat/lon you can query one of the online geo apis. Like this one: http://gws.maps.yahoo.com/FindLocation?q=35,-100&flags=T&gflags=R That turns lat/lon 35,-100 into a timezone (among other things). But, a geoip lookup is no usually very accurate. And in some cases wildly inaccurate. Previous Comments: [2009-08-07 01:36:05] ryan14 at mail dot com Description: PHP doesn't have a feature to display the time and date according to the country ip address. For example: Person has a video sharing website Person uploads video and video says it was uploaded at 7 Jan 2009 5.01pm using the USA based server's clock time and date If a person from the UK looks at the video details, they will see the date and time in USA time, not UK time. So PHP should have a Global date and time feature where when a video is uploaded to a server the date/time is displayed using the server's time, but if a person from another country views it then it will detect their ip address and display their country's date and time on the uploaded video details. -- Edit this bug report at http://bugs.php.net/?id=49185&edit=1
#49185 [NEW]: Feature Request: Global date/time
From: ryan14 at mail dot com Operating system: Windows/Linux PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: Feature Request: Global date/time Description: PHP doesn't have a feature to display the time and date according to the country ip address. For example: Person has a video sharing website Person uploads video and video says it was uploaded at 7 Jan 2009 5.01pm using the USA based server's clock time and date If a person from the UK looks at the video details, they will see the date and time in USA time, not UK time. So PHP should have a Global date and time feature where when a video is uploaded to a server the date/time is displayed using the server's time, but if a person from another country views it then it will detect their ip address and display their country's date and time on the uploaded video details. -- Edit bug report at http://bugs.php.net/?id=49185&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49185&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49185&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49185&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49185&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49185&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49185&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49185&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49185&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49185&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49185&r=support Expected behavior: http://bugs.php.net/fix.php?id=49185&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49185&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49185&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49185&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49185&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49185&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49185&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49185&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49185&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49185&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49185&r=mysqlcfg
#48824 [Bgs]: dateTime->add() doesn't properly account for days past the end of months
ID: 48824
Updated by: ras...@php.net
Reported By: brad at omnis dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Linux (CentOS 5.3)
PHP Version: 5.3.0
New Comment:
DateInterval is used for iteration. For stuff like this:
$db = new DateTime('2008-12-31');
$de = new DateTime('2009-12-31');
$di = DateInterval::createFromDateString('third tuesday of next
month');
$dp = new DatePeriod($db, $di, $de, DatePeriod::EXCLUDE_START_DATE);
foreach($dp as $dt) {
echo $dt->format("F jS\n") . "\n";
}
I also disagree with your suggestion that "calendar math" is "precision
math calculations". The strtotime approach is actually the precise
approach since you never have inconsistencies like this:
mysql> SELECT DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH);
+--+
| DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH) |
+--+
| 2009-02-28 23:59:59 |
+--+
mysql> SELECT DATE_SUB('2009-02-28 23:59:59',INTERVAL 1 MONTH);
+--+
| DATE_SUB('2009-02-28 23:59:59',INTERVAL 1 MONTH) |
+--+
| 2009-01-28 23:59:59 |
+--+
So, you essentially have
$a + month = $b
$b - month != $a
Or have 2 times 24-hours apart map to the same exact timestamp when you
add a month:
mysql> SELECT DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH);
+--+
| DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH) |
+--+
| 2009-02-28 23:59:59 |
+--+
mysql> SELECT DATE_ADD('2009-01-30 23:59:59',INTERVAL 1 MONTH);
+--+
| DATE_ADD('2009-01-30 23:59:59',INTERVAL 1 MONTH) |
+--+
| 2009-02-28 23:59:59 |
+--+
I understand why it works that way, but it certainly isn't ideal, nor
is it precise if you aren't expecting that. Neither way is perfect. We
chose to have all relative date operations follow the same rules.
Having Interval and Modify use different relative date rules would be
very confusing.
Previous Comments:
[2009-08-07 00:22:37] brad at omnis dot com
Why have dateInterval at all? If you don't want to have "2
different implementations". dateTime::modify() existed prior to PHP
5.3.0 and did the job of strtotime(). All dateInterval does at this
point is to confuse anyone who thinks it may add time in a
non-GNU-strtotime way and do calendar math.
If I wanted strtotime capability with dateTime objects I could just use
dateTime::modify() could I not?
What is the issue with having dateInterval work in a calendar math way
and having dateTime::modify() work the old unix way? Both sides would
be happy.
(Also, http://bugs.php.net/bug.php?id=43999 is about strtotime
specifically. There is nothing obvious that dateInterval has anything
to do with strtotime)
[2009-08-06 23:40:54] ras...@php.net
Well, it uses the same strtotime code. We are not going to have 2
different implementations here. I have no difficulty understanding that
some people might expect database-like behaviour, But at the same time,
there are also people who expect UNIX-like behaviour. You seem to be
discounting those, and in the end we had to choose one or the other.
And the reason it was marked bogus was because it had been filed
before. A quick search finds the previous bugs easily.
[2009-08-06 22:53:57] brad at omnis dot com
Notice I'm not complaining about the dateTime::modify() function, which
explicitly states it uses strtotime() format. I'm taking about a
function that explicitly states "Adds an amount of days, months, years,
hours, minutes and seconds to a DateTime object",
I'm not making any claim that you "made this stuff up". I would argue
that the GNU guys got it wrong (see the example of how databases handle
it for an alternate point of view), but that's not the issue. I'm
talking about PHP here, not GNU.
What is so difficult to understand that people using these sets of
functions might expect that it works in the same manner that databases
do.
I've been using PHP for 10+ years, I'm not trying to make you mad, I'm
trying to help make PHP better by filing bug reports, and what do I get
in response to a legitimate issue? I get it marked as BOGUS.
A compromise of making the dateInterval constr
#48824 [Bgs]: dateTime->add() doesn't properly account for days past the end of months
ID: 48824 User updated by: brad at omnis dot com Reported By: brad at omnis dot com Status: Bogus Bug Type: Date/time related Operating System: Linux (CentOS 5.3) PHP Version: 5.3.0 New Comment: Why have dateInterval at all? If you don't want to have "2 different implementations". dateTime::modify() existed prior to PHP 5.3.0 and did the job of strtotime(). All dateInterval does at this point is to confuse anyone who thinks it may add time in a non-GNU-strtotime way and do calendar math. If I wanted strtotime capability with dateTime objects I could just use dateTime::modify() could I not? What is the issue with having dateInterval work in a calendar math way and having dateTime::modify() work the old unix way? Both sides would be happy. (Also, http://bugs.php.net/bug.php?id=43999 is about strtotime specifically. There is nothing obvious that dateInterval has anything to do with strtotime) Previous Comments: [2009-08-06 23:40:54] ras...@php.net Well, it uses the same strtotime code. We are not going to have 2 different implementations here. I have no difficulty understanding that some people might expect database-like behaviour, But at the same time, there are also people who expect UNIX-like behaviour. You seem to be discounting those, and in the end we had to choose one or the other. And the reason it was marked bogus was because it had been filed before. A quick search finds the previous bugs easily. [2009-08-06 22:53:57] brad at omnis dot com Notice I'm not complaining about the dateTime::modify() function, which explicitly states it uses strtotime() format. I'm taking about a function that explicitly states "Adds an amount of days, months, years, hours, minutes and seconds to a DateTime object", I'm not making any claim that you "made this stuff up". I would argue that the GNU guys got it wrong (see the example of how databases handle it for an alternate point of view), but that's not the issue. I'm talking about PHP here, not GNU. What is so difficult to understand that people using these sets of functions might expect that it works in the same manner that databases do. I've been using PHP for 10+ years, I'm not trying to make you mad, I'm trying to help make PHP better by filing bug reports, and what do I get in response to a legitimate issue? I get it marked as BOGUS. A compromise of making the dateInterval constructor have a "[, bool $calendarMath]" (or a bitmask) option would be welcome, but leaving it as is, I believe will lead to confusion and headache for those wishing to use these functions for anything that requires precision math calculations. [2009-08-06 22:32:25] ras...@php.net We didn't make this stuff up. We followed the GNU strtotime implementation. And it isn't as cut and dry as you make it sound that shrinking the interval is the right approach when you are at the end of the month and the next month is shorter. Given the complexity of this stuff, we figured following traditional UNIX practice would make the most sense. You can read about it here: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC114 And if you read this section: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC120 They even specifically mention this case: "The fuzz in units can cause problems with relative items. For example, 2003-07-31 -1 month might evaluate to 2003-07-01, because 2003-06-31 is an invalid date. To determine the previous month more reliably, you can ask for the month before the 15th of the current month. " So, can we drop this "The PHP Devs don't want to write correct code" ranting please, and recognize that you simply don't agree with our choice. It has nothing to do with correctness. Your shell's date command behaves exactly the same way, as does any other UNIX command that uses relative dates. [2009-08-06 18:17:24] brad at omnis dot com Just to be clear, because the PHP devs don't want to write correct code and would rather rely on a broken library, this bug gets marked as bogus and everyone has to deal with an inferior date function. To point out that my idea of date math is not incorrect, here is postgresql (also tested in MySQL and Oracle which provide the same results): query: select '01-31-2009 23:59:59'::timestamp + '1 month'::interval result: 2009-02-28T23:59:59 [2009-08-06 13:35:24] j...@php.net DateInterval uses the same parser as strtotime(). The remainder of the comments for this report
#48824 [Bgs]: dateTime->add() doesn't properly account for days past the end of months
ID: 48824 Updated by: ras...@php.net Reported By: brad at omnis dot com Status: Bogus Bug Type: Date/time related Operating System: Linux (CentOS 5.3) PHP Version: 5.3.0 New Comment: Well, it uses the same strtotime code. We are not going to have 2 different implementations here. I have no difficulty understanding that some people might expect database-like behaviour, But at the same time, there are also people who expect UNIX-like behaviour. You seem to be discounting those, and in the end we had to choose one or the other. And the reason it was marked bogus was because it had been filed before. A quick search finds the previous bugs easily. Previous Comments: [2009-08-06 22:53:57] brad at omnis dot com Notice I'm not complaining about the dateTime::modify() function, which explicitly states it uses strtotime() format. I'm taking about a function that explicitly states "Adds an amount of days, months, years, hours, minutes and seconds to a DateTime object", I'm not making any claim that you "made this stuff up". I would argue that the GNU guys got it wrong (see the example of how databases handle it for an alternate point of view), but that's not the issue. I'm talking about PHP here, not GNU. What is so difficult to understand that people using these sets of functions might expect that it works in the same manner that databases do. I've been using PHP for 10+ years, I'm not trying to make you mad, I'm trying to help make PHP better by filing bug reports, and what do I get in response to a legitimate issue? I get it marked as BOGUS. A compromise of making the dateInterval constructor have a "[, bool $calendarMath]" (or a bitmask) option would be welcome, but leaving it as is, I believe will lead to confusion and headache for those wishing to use these functions for anything that requires precision math calculations. [2009-08-06 22:32:25] ras...@php.net We didn't make this stuff up. We followed the GNU strtotime implementation. And it isn't as cut and dry as you make it sound that shrinking the interval is the right approach when you are at the end of the month and the next month is shorter. Given the complexity of this stuff, we figured following traditional UNIX practice would make the most sense. You can read about it here: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC114 And if you read this section: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC120 They even specifically mention this case: "The fuzz in units can cause problems with relative items. For example, 2003-07-31 -1 month might evaluate to 2003-07-01, because 2003-06-31 is an invalid date. To determine the previous month more reliably, you can ask for the month before the 15th of the current month. " So, can we drop this "The PHP Devs don't want to write correct code" ranting please, and recognize that you simply don't agree with our choice. It has nothing to do with correctness. Your shell's date command behaves exactly the same way, as does any other UNIX command that uses relative dates. [2009-08-06 18:17:24] brad at omnis dot com Just to be clear, because the PHP devs don't want to write correct code and would rather rely on a broken library, this bug gets marked as bogus and everyone has to deal with an inferior date function. To point out that my idea of date math is not incorrect, here is postgresql (also tested in MySQL and Oracle which provide the same results): query: select '01-31-2009 23:59:59'::timestamp + '1 month'::interval result: 2009-02-28T23:59:59 [2009-08-06 13:35:24] j...@php.net DateInterval uses the same parser as strtotime(). [2009-07-07 16:56:59] brad at omnis dot com >From a brief reading of the source code, dateTime->add() doesn't *appear* use the underlying strtotime library, so I don't see why this function should be forced to have the same weakness of that function. IMO, these date functions would be far more useful if they adhere to common date manipulation ideals instead of using simple math as they are currently doing. As it stands now, the dateTime->add() function cannot be relied upon for any sort of accounting math and IMO completely defeats the purpose of specialized dateTime functions. 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/48824 -- Edit this bug report at http://bugs.php.net/?id=48824
#48824 [Bgs]: dateTime->add() doesn't properly account for days past the end of months
ID: 48824 User updated by: brad at omnis dot com Reported By: brad at omnis dot com Status: Bogus Bug Type: Date/time related Operating System: Linux (CentOS 5.3) PHP Version: 5.3.0 New Comment: Notice I'm not complaining about the dateTime::modify() function, which explicitly states it uses strtotime() format. I'm taking about a function that explicitly states "Adds an amount of days, months, years, hours, minutes and seconds to a DateTime object", I'm not making any claim that you "made this stuff up". I would argue that the GNU guys got it wrong (see the example of how databases handle it for an alternate point of view), but that's not the issue. I'm talking about PHP here, not GNU. What is so difficult to understand that people using these sets of functions might expect that it works in the same manner that databases do. I've been using PHP for 10+ years, I'm not trying to make you mad, I'm trying to help make PHP better by filing bug reports, and what do I get in response to a legitimate issue? I get it marked as BOGUS. A compromise of making the dateInterval constructor have a "[, bool $calendarMath]" (or a bitmask) option would be welcome, but leaving it as is, I believe will lead to confusion and headache for those wishing to use these functions for anything that requires precision math calculations. Previous Comments: [2009-08-06 22:32:25] ras...@php.net We didn't make this stuff up. We followed the GNU strtotime implementation. And it isn't as cut and dry as you make it sound that shrinking the interval is the right approach when you are at the end of the month and the next month is shorter. Given the complexity of this stuff, we figured following traditional UNIX practice would make the most sense. You can read about it here: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC114 And if you read this section: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC120 They even specifically mention this case: "The fuzz in units can cause problems with relative items. For example, 2003-07-31 -1 month might evaluate to 2003-07-01, because 2003-06-31 is an invalid date. To determine the previous month more reliably, you can ask for the month before the 15th of the current month. " So, can we drop this "The PHP Devs don't want to write correct code" ranting please, and recognize that you simply don't agree with our choice. It has nothing to do with correctness. Your shell's date command behaves exactly the same way, as does any other UNIX command that uses relative dates. [2009-08-06 18:17:24] brad at omnis dot com Just to be clear, because the PHP devs don't want to write correct code and would rather rely on a broken library, this bug gets marked as bogus and everyone has to deal with an inferior date function. To point out that my idea of date math is not incorrect, here is postgresql (also tested in MySQL and Oracle which provide the same results): query: select '01-31-2009 23:59:59'::timestamp + '1 month'::interval result: 2009-02-28T23:59:59 [2009-08-06 13:35:24] j...@php.net DateInterval uses the same parser as strtotime(). [2009-07-07 16:56:59] brad at omnis dot com >From a brief reading of the source code, dateTime->add() doesn't *appear* use the underlying strtotime library, so I don't see why this function should be forced to have the same weakness of that function. IMO, these date functions would be far more useful if they adhere to common date manipulation ideals instead of using simple math as they are currently doing. As it stands now, the dateTime->add() function cannot be relied upon for any sort of accounting math and IMO completely defeats the purpose of specialized dateTime functions. [2009-07-07 09:50:48] sjoerd-php at linuxonly dot nl Thank you for your report. The issue you report is not a bug. See also bug #43999. 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/48824 -- Edit this bug report at http://bugs.php.net/?id=48824&edit=1
#43999 [Bgs]: Date is not 'next month' as expected
ID: 43999
Updated by: ras...@php.net
Reported By: gavinp at tbs dot uk dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Debian
PHP Version: 4.4.8
New Comment:
For people who run across this one. We went with the traditional UNIX
approach for relative dates. You can read about it here:
http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC120
It is consistent with 'date' and various other command line UNIX tools
you likely use quite often.
Previous Comments:
[2008-01-31 18:07:49] der...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
just searching for "next month" in the bug system, provides the
following hits in the first two pages:
http://bugs.php.net/bug.php?id=36912
http://bugs.php.net/bug.php?id=38279
http://bugs.php.net/bug.php?id=39139
http://bugs.php.net/bug.php?id=41547
http://bugs.php.net/bug.php?id=41551
http://bugs.php.net/bug.php?id=43169
granted, some of them are for "last month". It is still not a bug
however, the strtotime() function adds one to the month - it does *not
reset* the day of month. 2008-01-31 turns therefore into 2008-02-31,
which does not exist (and therefore overflows to 2008-03-02). The same
happens if we add 3 months to 2007-11-30 -> 2007-14-30 -> 2008-02-30 ->
2008-03-01 (strtotime("2007-11-30 third month") or strtotime("2007-11-30
+3 months"). What you really want to do, is:
[2008-01-31 16:55:04] gavinp at tbs dot uk dot com
Excatly. Hence why it's a bug.
I'm asking PHP to add 1 to the month number. Not to add 31 days to the
month.
strtotime('next month', $basedate); where $basedate = today
The expected result would be to produce the next month, not to add 31
days and provide the month, which may, or may not be, the next month.
[2008-01-31 16:37:20] scott at slerman dot net
Today is January 31st.
Adding 1 to the month would produce February 31st.
February 31st does not exist, so it is converted to March 2nd (or March
3rd during non-leap years).
The GNU date format documentation
(http://www.gnu.org/software/tar/manual/html_node/tar_113.html) gives
you the solution of getting the next month after the 15th of the current
month. You can do this in PHP with the second parameter to strtotime:
strtotime('next month', mktime(0, 0, 0, idate('m'), 15))
[2008-01-31 16:20:48] gavinp at tbs dot uk dot com
Description:
Hi der...@php.net,
I have not posted this twice,(however because you locked the last bug I
now have to and in case another user has ... your search system will
need some work then. I could not find a bug describing the same problem.
Please direct me to the correct place that is an open bug and I will
happy tag this onto the end of it.
strtotime('next month', $basedate); where $basedate = today.
Should output the next month. The next month from today is Feb. Simple.
That is the 'expected behaviour'.
That's like saying 2+2 = 4 except on Fridays when it = 5, and then
saying because it's always been like this then it's 'Expected.'
If you are going to refer me to the documentation, please direct me to
the documentations excact location where it says 'next month on the last
day of the month should be two months instead of one.' I can not find
this part in the documentation anywhere also.
However I would love to eat humble pie so please do show me.
Reproduce code:
---
$basedate = time();
$date1 = strtotime('next month', $basedate);
$date2 = strtotime('+1 month', $basedate);
$date3 = strtotime('first month', $basedate);
$date4 = mktime(0, 0, 0, date("m")+1, date("d"), date("Y"));
$format1 = date('F', $date1);
$format2 = date('F', $date2);
$format3 = date('F', $date3);
$format4 = date('F', $date4);
echo $format1;
echo $format2;
echo $format3;
echo $format4;
Expected result:
February
February
February
February
Actual result:
--
March
March
March
March
--
Edit this bug report at http://bugs.php.net/?id=43999&edit=1
#48824 [Bgs]: dateTime->add() doesn't properly account for days past the end of months
ID: 48824
Updated by: ras...@php.net
Reported By: brad at omnis dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Linux (CentOS 5.3)
PHP Version: 5.3.0
New Comment:
We didn't make this stuff up. We followed the GNU strtotime
implementation. And it isn't as cut and dry as you make it sound that
shrinking the interval is the right approach when you are at the end of
the month and the next month is shorter.
Given the complexity of this stuff, we figured following traditional
UNIX practice would make the most sense. You can read about it here:
http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC114
And if you read this section:
http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC120
They even specifically mention this case:
"The fuzz in units can cause problems with relative items. For example,
2003-07-31 -1 month might evaluate to 2003-07-01, because 2003-06-31
is an invalid date. To determine the previous month more reliably, you
can ask for the month before the 15th of the current month. "
So, can we drop this "The PHP Devs don't want to write correct code"
ranting please, and recognize that you simply don't agree with our
choice. It has nothing to do with correctness. Your shell's date
command behaves exactly the same way, as does any other UNIX command
that uses relative dates.
Previous Comments:
[2009-08-06 18:17:24] brad at omnis dot com
Just to be clear, because the PHP devs don't want to write correct code
and would rather rely on a broken library, this bug gets marked as bogus
and everyone has to deal with an inferior date function.
To point out that my idea of date math is not incorrect, here is
postgresql (also tested in MySQL and Oracle which provide the same
results):
query: select '01-31-2009 23:59:59'::timestamp + '1 month'::interval
result: 2009-02-28T23:59:59
[2009-08-06 13:35:24] j...@php.net
DateInterval uses the same parser as strtotime().
[2009-07-07 16:56:59] brad at omnis dot com
>From a brief reading of the source code, dateTime->add() doesn't
*appear* use the underlying strtotime library, so I don't see why this
function should be forced to have the same weakness of that function.
IMO, these date functions would be far more useful if they adhere to
common date manipulation ideals instead of using simple math as they are
currently doing.
As it stands now, the dateTime->add() function cannot be relied upon
for any sort of accounting math and IMO completely defeats the purpose
of specialized dateTime functions.
[2009-07-07 09:50:48] sjoerd-php at linuxonly dot nl
Thank you for your report.
The issue you report is not a bug. See also bug #43999.
[2009-07-06 22:24:39] brad at omnis dot com
Description:
dateTime->add(dateInterval) isn't applying proper calendar math when
adding intervals.
Reproduce code:
---
$dateTest = new dateTime('2008-01-31',new dateTimeZone("GMT"));
print_r($dateTest);
$dateTest->add(new dateInterval('P1M'));
print_r($dateTest);
Expected result:
DateTime Object
(
[date] => 2008-01-31 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
DateTime Object
(
[date] => 2008-02-28 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
Actual result:
--
DateTime Object
(
[date] => 2008-01-31 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
DateTime Object
(
[date] => 2008-03-02 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
--
Edit this bug report at http://bugs.php.net/?id=48824&edit=1
#47761 [Com]: Since 5.2.9 SoapClient no longer attempts Basic auth to retrieve a WSDL file
ID: 47761 Comment by: sriram dot natarajan at gmail dot com Reported By: marques at displague dot com Status: Open Bug Type: SOAP related Operating System: * PHP Version: 5.2.9 New Comment: why is there still a need to support basic authentication ? can u kindly explain that scenario ? Previous Comments: [2009-03-24 13:53:48] marques at displague dot com Description: Since 5.2.9, SoapClient no longer attempts HTTP Basic authentication to retrieve a wsdl file. Prior to this version Basic was attempted and Digest was not. Digest should also be attempted but that is a matter for another bug. The SoapClient option 'authentication' has no effect on wsdl retrieval. A work-around is to fetch the WSDL file manually or via PHP commands within the SOAP code, but that method can be cumbersome because digest auth code has to be written from scratch and Bug #47759 (chunk encoding) can get in the way. -- Edit this bug report at http://bugs.php.net/?id=47761&edit=1
#49184 [NEW]: INPUT_SERVER returns NULL for set variables (CLI)
From: m dot kurzyna at crystalpoint dot pl Operating system: Linux PHP version: 5.3.0 PHP Bug Type: Filter related Bug description: INPUT_SERVER returns NULL for set variables (CLI) Description: This is very similar to #44779, however my report regards variables set as environment variables when running CLI. A variable is visible in $_SERVER but INPUT_SERVER returns NULL. Setting via SetEnv in apache and when running as mod_php is fine. Reproduce code: --- Expected result: $ ENV_NAME=var php /tmp/t.php string(3) "var" string(3) "var" Actual result: -- $ ENV_NAME=var php /tmp/t.php NULL string(3) "var" -- Edit bug report at http://bugs.php.net/?id=49184&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49184&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49184&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49184&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49184&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49184&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49184&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49184&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49184&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49184&r=support Expected behavior: http://bugs.php.net/fix.php?id=49184&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49184&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49184&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49184&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49184&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49184&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49184&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49184&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49184&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49184&r=mysqlcfg
#49173 [Fbk]: Php don't work with mod_fcgid if I load a extension
ID: 49173 Updated by: srina...@php.net Reported By: malina dot laszlo at malina dot hu Status: Feedback Bug Type: Dynamic loading Operating System: Debian Lenny PHP Version: 5.3.0 New Comment: i very much doubt if this is a php bug. i bet that extension like gd.so is probably depending on a library which it is probably unable to load in your fastcgi environment. you can verify this by running ldd on gd.so and if there is any dependent library that is not in /lib or /usr/lib (or for that any matter any directory that is not in /etc/ld.so.conf.d/*.conf) then this could be the cause. to confirm this is the issue, you could try loading an extension which does not depend on libraries that is not in /lib or /usr/lib. if it works fine, then you could either a) update your apachectl script to add LD_LIBRARY_PATH to include all your dependent library locations b) create a custom .conf file under /etc/ld.so.conf.d which contains the list of directories to search in your environment. Previous Comments: [2009-08-06 09:43:57] malina dot laszlo at malina dot hu Hi! I tried to compile the PHP (not snapshot, but release). There are two ways to do: 1. I am updating system libraries (libgd, libpng, etc) and compiling gd extension by shared (--with-gd=shared,/usr and png,jpg,xpm, freetype,etc by shared) 2. I compiling gd extension by "embedded" (it is not shared). (--with-gd [it is embedded for me] and png, jpg,xpm, etc is not shared) Results: Point 1: it is failed, same error Point 2: this is good, no error! I will try to compile snapshot-php5.3 by shared and "embedded". I'm curious :) [2009-08-06 08:57:47] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-06 08:07:09] malina dot laszlo at malina dot hu Hi! I am trying to load extensions and each works well except for the gd.so. If I load gd, server send me "Status 500" and written above logs. Before there was already a compiling problem (gdhelper), but this is no, without error compiled. Thanks for your help! Bearcheese [2009-08-06 00:31:26] malina dot laszlo at malina dot hu Description: Hello! I compiled php-5.3.0 (CGI), apache-2.2.12 (mpm-worker) and mod_fcgid-2.2.0 on Debian Lenny. I have more extension: mysql, mysqli, pdo, gd, gettext, memcache, imagick, idn, etc. When I give extension_dir (with absoluth path) and I does NOT allow to load extensions then no problem (and no extension). When I does allow to load only ONE extension (for example gd.so), then the server send me "Internal server error" (status 500). I can see in apache error-log: [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error. [info] (104)Connection reset by peer: mod_fcgid: can't read data from fcgid handler [warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request function What is problem? (Sorry for my bad English!) -- Edit this bug report at http://bugs.php.net/?id=49173&edit=1
#49182 [Com]: PHP CGI always outputs the shebang line
ID: 49182 Comment by: salsi at icosaedro dot it Reported By: salsi at icosaedro dot it Status: Feedback Bug Type: CGI related Operating System: Slackware 12.0 PHP Version: 5.3SVN-2009-08-06 (SVN) New Comment: I'm using Apache 2.2.8 + suexec without any support for PHP (it executes only CGI programs) and all worked well with PHP 5.2.5 I used until now. But this should not care, as in my opinion the shebang should not be displayed once the script has been detected to be executed as a program. I configured PHP as follows: ./configure \ --disable-all \ --prefix=/usr/local/php-5.3.0 \ --exec-prefix=/usr/local/php-5.3.0 \ --disable-rpath \ --disable-ipv6 \ --enable-ftp=shared \ --enable-sockets=shared \ --enable-tokenizer \ --with-gnu-ld=shared \ --with-pgsql=shared \ --enable-session \ --enable-posix \ --with-pcre-regex \ --enable-mbstring=all \ --enable-mbregex \ --enable-libxml \ --enable-xml \ --enable-dom \ --enable-pdo I can also confirm that with the old version of PHP the shebang line did not came out under Apache and neither did it under the command line. Previous Comments: [2009-08-06 20:01:38] j...@php.net What webserver? How did you configure PHP into it? [2009-08-06 18:59:41] salsi at icosaedro dot it Description: Executing any PHP CGI script always results in the shebang line being displayed along the correct HTML code of the WEB page. This happens with and without the --enable-discard-path configuration flag (although I'm not really sure this flag be realted to the issue or not). Reproduce code: --- #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini Expected result: $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html 5.3.1-dev Actual result: -- $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini 5.3.1-dev -- Edit this bug report at http://bugs.php.net/?id=49182&edit=1
#49122 [Opn->Fbk]: undefined reference to mysqlnd_stmt_next_result on compile with --with-mysqli
ID: 49122 Updated by: j...@php.net Reported By: gabrycucciolo84pv at fastwebnet dot it -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Centos 4 PHP Version: 5.3, 6 (2009-08-04) Assigned To: andrey New Comment: Using fresh sources means "grab latest snapshot, untar, configure, compile". Try that. Previous Comments: [2009-08-06 14:07:03] gabrycucciolo84pv at fastwebnet dot it fresh sources you mean latest cvn snapshot? [2009-08-06 14:06:08] gabrycucciolo84pv at fastwebnet dot it It does not even start stating that it can't find mysql installation and to reinstall it. With 5.2.10 everything works like a charm... [2009-08-06 09:00:47] j...@php.net Please use fresh sources and preferrably build outside source tree. "make clean" after configure with different options might help too.. [2009-08-05 15:21:49] and...@php.net The code is under #if defined(HAVE_STMT_NEXT_RESULT) && defined(MYSQLI_USE_MYSQLND) which means tha mysqli_stmt_more_results and mysqli_stmt_next_result are not available in libmysql builds. Strangely one of the functions call mysqlnd_ but the other mysql_ ->jani's change. mysqlnd defines macros, so one doesn't need to use mysqlnd_xxx but mysql_xxx. This should be some misconfiguration. Can you try with --with-mysqli=mysqlnd instead of --with-mysqli ? Andrey [2009-08-05 15:11:50] and...@php.net Jani, only libmysql6 has mysql_stmt_more_results . mysqlnd has it always. I suppose the people compile with libmysql which is not 6 and get this unresolved symbols. Andrey 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/49122 -- Edit this bug report at http://bugs.php.net/?id=49122&edit=1
#49179 [Opn->Bgs]: zero problem in if and switch
ID: 49179
Updated by: j...@php.net
Reported By: steve at ezd dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: linux
PHP Version: 5.2.10
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
PLEASE search the bug database before you submit same issue as a bug
again. This is not a bug. It's said in the manual too, try reading that
also.
Previous Comments:
[2009-08-06 16:05:55] steve at ezd dot com
Description:
please run source code, it's self explained
it seems that when use 0 to compare with string, it returns true all
the time,
problem in if is when using ==, === has no problem
in switch case, it matches the first non number case
Reproduce code:
---
if (0=="a") echo "this is ture.";
$check=0;
switch ($check)
{
case 'a':
echo "this is a ";
break;
default :
echo "no match";
}
Expected result:
no match
Actual result:
--
this is ture.this is a
--
Edit this bug report at http://bugs.php.net/?id=49179&edit=1
#49181 [Opn->Fbk]: Parent: child process exited with status 3221225477 -- Restarting
ID: 49181
Updated by: j...@php.net
Reported By: adaro2000 at yahoo dot fr
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: Win XP Pro Version 2002 SP2
PHP Version: 5.2.10
New Comment:
Try run the script on command line using the CLI binary.
Previous Comments:
[2009-08-06 18:15:52] adaro2000 at yahoo dot fr
Description:
I install Xampp xampp-win32-1.7.0-installer. Php version is 5.2.8,
Mysql version 5.1.30, Apache version 2.2.11
I'm using PDO to query my database.
As i query out a result of more than one column, apache restart, and in
log i read :
[Thu Aug 06 17:53:23 2009] [notice] cannot use a full URL in a 401
ErrorDocument directive --- ignoring!
[Thu Aug 06 17:53:31 2009] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Thu Aug 06 17:53:31 2009] [notice] Digest: generating secret for
digest authentication ...
[Thu Aug 06 17:53:31 2009] [notice] Digest: done
Reproduce code:
---
This produces an error :
query("SELECT login, pass FROM admin");
$result->setFetchMode(PDO::FETCH_OBJ);
foreach ($result AS $line){
echo ''.$line->login.'';
echo ''.$line->pass.'';
}
?>
Expected result:
I hope this will print data, but not.
I run this without problem :
query("SELECT COUNT(*) as Me FROM admin");
$result->setFetchMode(PDO::FETCH_OBJ);
foreach ($result AS $line){
echo ''.$line->Me.'';
}
?>
It prints the exact number.
Actual result:
--
The browser seems to load the page, but i have a prompt Apache HTTP
encouter an error and must... and the log is what i show on the top.
Can you help me please ?
--
Edit this bug report at http://bugs.php.net/?id=49181&edit=1
#49182 [Opn->Fbk]: PHP CGI always outputs the shebang line
ID: 49182 Updated by: j...@php.net Reported By: salsi at icosaedro dot it -Status: Open +Status: Feedback Bug Type: CGI related Operating System: Slackware 12.0 PHP Version: 5.3SVN-2009-08-06 (SVN) New Comment: What webserver? How did you configure PHP into it? Previous Comments: [2009-08-06 18:59:41] salsi at icosaedro dot it Description: Executing any PHP CGI script always results in the shebang line being displayed along the correct HTML code of the WEB page. This happens with and without the --enable-discard-path configuration flag (although I'm not really sure this flag be realted to the issue or not). Reproduce code: --- #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini Expected result: $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html 5.3.1-dev Actual result: -- $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini 5.3.1-dev -- Edit this bug report at http://bugs.php.net/?id=49182&edit=1
#49183 [Opn->Fbk]: dns_get_record does not return NAPTR records when you query dot tel domains!
ID: 49183 Updated by: paj...@php.net Reported By: sunnyseh at hotmail dot com -Status: Open +Status: Feedback Bug Type: Network related Operating System: windows PHP Version: 5.3.0 -Assigned To: +Assigned To: pajoye New Comment: Does it return it on unix? Which domain did you use to test? Previous Comments: [2009-08-06 19:07:30] sunnyseh at hotmail dot com Description: when you use the dns_get_record function it only returns txt records from dot tel domains. When you use the DNS_NAPTR option it still doesnt return dot tel NAPTR records. Is this supported functionality or on the roadmap? -- Edit this bug report at http://bugs.php.net/?id=49183&edit=1
#49183 [NEW]: dns_get_record does not return NAPTR records when you query dot tel domains!
From: sunnyseh at hotmail dot com Operating system: windows PHP version: 5.3.0 PHP Bug Type: Network related Bug description: dns_get_record does not return NAPTR records when you query dot tel domains! Description: when you use the dns_get_record function it only returns txt records from dot tel domains. When you use the DNS_NAPTR option it still doesnt return dot tel NAPTR records. Is this supported functionality or on the roadmap? -- Edit bug report at http://bugs.php.net/?id=49183&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49183&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49183&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49183&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49183&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49183&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49183&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49183&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49183&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49183&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49183&r=support Expected behavior: http://bugs.php.net/fix.php?id=49183&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49183&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49183&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49183&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49183&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49183&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49183&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49183&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49183&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49183&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49183&r=mysqlcfg
#49182 [NEW]: PHP CGI always outputs the shebang line
From: salsi at icosaedro dot it Operating system: Slackware 12.0 PHP version: 5.3SVN-2009-08-06 (SVN) PHP Bug Type: CGI related Bug description: PHP CGI always outputs the shebang line Description: Executing any PHP CGI script always results in the shebang line being displayed along the correct HTML code of the WEB page. This happens with and without the --enable-discard-path configuration flag (although I'm not really sure this flag be realted to the issue or not). Reproduce code: --- #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini Expected result: $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html 5.3.1-dev Actual result: -- $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini 5.3.1-dev -- Edit bug report at http://bugs.php.net/?id=49182&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49182&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49182&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49182&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49182&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49182&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49182&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49182&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49182&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49182&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49182&r=support Expected behavior: http://bugs.php.net/fix.php?id=49182&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49182&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49182&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49182&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49182&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49182&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49182&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49182&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49182&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49182&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49182&r=mysqlcfg
#48824 [Bgs]: dateTime->add() doesn't properly account for days past the end of months
ID: 48824
User updated by: brad at omnis dot com
Reported By: brad at omnis dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Linux (CentOS 5.3)
PHP Version: 5.3.0
New Comment:
Just to be clear, because the PHP devs don't want to write correct code
and would rather rely on a broken library, this bug gets marked as bogus
and everyone has to deal with an inferior date function.
To point out that my idea of date math is not incorrect, here is
postgresql (also tested in MySQL and Oracle which provide the same
results):
query: select '01-31-2009 23:59:59'::timestamp + '1 month'::interval
result: 2009-02-28T23:59:59
Previous Comments:
[2009-08-06 13:35:24] j...@php.net
DateInterval uses the same parser as strtotime().
[2009-07-07 16:56:59] brad at omnis dot com
>From a brief reading of the source code, dateTime->add() doesn't
*appear* use the underlying strtotime library, so I don't see why this
function should be forced to have the same weakness of that function.
IMO, these date functions would be far more useful if they adhere to
common date manipulation ideals instead of using simple math as they are
currently doing.
As it stands now, the dateTime->add() function cannot be relied upon
for any sort of accounting math and IMO completely defeats the purpose
of specialized dateTime functions.
[2009-07-07 09:50:48] sjoerd-php at linuxonly dot nl
Thank you for your report.
The issue you report is not a bug. See also bug #43999.
[2009-07-06 22:24:39] brad at omnis dot com
Description:
dateTime->add(dateInterval) isn't applying proper calendar math when
adding intervals.
Reproduce code:
---
$dateTest = new dateTime('2008-01-31',new dateTimeZone("GMT"));
print_r($dateTest);
$dateTest->add(new dateInterval('P1M'));
print_r($dateTest);
Expected result:
DateTime Object
(
[date] => 2008-01-31 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
DateTime Object
(
[date] => 2008-02-28 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
Actual result:
--
DateTime Object
(
[date] => 2008-01-31 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
DateTime Object
(
[date] => 2008-03-02 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
--
Edit this bug report at http://bugs.php.net/?id=48824&edit=1
#49181 [NEW]: Parent: child process exited with status 3221225477 -- Restarting
From: adaro2000 at yahoo dot fr
Operating system: Win XP Pro Version 2002 SP2
PHP version: 5.2.10
PHP Bug Type: Apache2 related
Bug description: Parent: child process exited with status 3221225477 --
Restarting
Description:
I install Xampp xampp-win32-1.7.0-installer. Php version is 5.2.8, Mysql
version 5.1.30, Apache version 2.2.11
I'm using PDO to query my database.
As i query out a result of more than one column, apache restart, and in
log i read :
[Thu Aug 06 17:53:23 2009] [notice] cannot use a full URL in a 401
ErrorDocument directive --- ignoring!
[Thu Aug 06 17:53:31 2009] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Thu Aug 06 17:53:31 2009] [notice] Digest: generating secret for digest
authentication ...
[Thu Aug 06 17:53:31 2009] [notice] Digest: done
Reproduce code:
---
This produces an error :
query("SELECT login, pass FROM admin");
$result->setFetchMode(PDO::FETCH_OBJ);
foreach ($result AS $line){
echo ''.$line->login.'';
echo ''.$line->pass.'';
}
?>
Expected result:
I hope this will print data, but not.
I run this without problem :
query("SELECT COUNT(*) as Me FROM admin");
$result->setFetchMode(PDO::FETCH_OBJ);
foreach ($result AS $line){
echo ''.$line->Me.'';
}
?>
It prints the exact number.
Actual result:
--
The browser seems to load the page, but i have a prompt Apache HTTP
encouter an error and must... and the log is what i show on the top.
Can you help me please ?
--
Edit bug report at http://bugs.php.net/?id=49181&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49181&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49181&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49181&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49181&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49181&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49181&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49181&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49181&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49181&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49181&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49181&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49181&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49181&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49181&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49181&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49181&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49181&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49181&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49181&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49181&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49181&r=mysqlcfg
#48882 [Com]: "PHP Startup: Timezone database is corrupt"
ID: 48882 Comment by: bug dot dmca at gmail dot com Reported By: vonpreussen at 2secure dot us Status: No Feedback Bug Type: Date/time related Operating System: centos 5 PHP Version: 5.3.0 New Comment: apache module fixed by adding TZ=GMT in init.d script. Don't know if there any other way, but at least it's working. Previous Comments: [2009-08-06 17:05:52] bug dot dmca at gmail dot com cli fixed after adding TZ=GMT in /etc/profile apache module still not working. [2009-08-06 16:50:46] bug dot odesk at gmail dot com CentOS 5, php 5.3 cli. tzdata 2009i. $ php -v PHP Strict Standards: PHP Startup: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead in Unknown on line 0 PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 Segmentation fault strace log. http://pastebin.com/f2b4d38c7 [2009-07-18 01:00:01] 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". [2009-07-10 21:55:33] vonpreussen at 2secure dot us no. yum install. [2009-07-10 21:31:08] der...@php.net Did you compile PHP yourself? 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/48882 -- Edit this bug report at http://bugs.php.net/?id=48882&edit=1
#49180 [NEW]: Feature Request
From: jmarois at ca dot ibm dot com Operating system: Irrelevant PHP version: 5.2.10 PHP Bug Type: Feature/Change Request Bug description: Feature Request Description: About your Data Filters First the validation filters. You defined: FILTER_VALIDATE_EMAIL, FILTER_VALIDATE_IP and FILTER_VALIDATE_URL. I request adding: FILTER_VALIDATE_MAC for MAC addresses, considering (1) the six groups of two hexadecimal digits, separated by hyphens (-) or colons (:) format, and (2) three groups of four hexadecimal digits separated by dots (.) format. Of course, not forgetting the default of twelve hexadecimal digits. Next the sanitizing filters. I request adding: FILTER_SANITIZE_MAC for MAC addresses, which would remove all characters except hexadecimal digits. Reproduce code: --- --- >From manual page: filter.filters.validate --- -- Edit bug report at http://bugs.php.net/?id=49180&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49180&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49180&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49180&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49180&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49180&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49180&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49180&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49180&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49180&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49180&r=support Expected behavior: http://bugs.php.net/fix.php?id=49180&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49180&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49180&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49180&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49180&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49180&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49180&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49180&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49180&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49180&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49180&r=mysqlcfg
#48882 [Com]: "PHP Startup: Timezone database is corrupt"
ID: 48882 Comment by: bug dot dmca at gmail dot com Reported By: vonpreussen at 2secure dot us Status: No Feedback Bug Type: Date/time related Operating System: centos 5 PHP Version: 5.3.0 New Comment: cli fixed after adding TZ=GMT in /etc/profile apache module still not working. Previous Comments: [2009-08-06 16:50:46] bug dot odesk at gmail dot com CentOS 5, php 5.3 cli. tzdata 2009i. $ php -v PHP Strict Standards: PHP Startup: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead in Unknown on line 0 PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 Segmentation fault strace log. http://pastebin.com/f2b4d38c7 [2009-07-18 01:00:01] 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". [2009-07-10 21:55:33] vonpreussen at 2secure dot us no. yum install. [2009-07-10 21:31:08] der...@php.net Did you compile PHP yourself? [2009-07-10 19:49:48] vonpreussen at 2secure dot us Description: updated php and it now fails every time over timezone issue. had latest tz data (tzdata-2009j) and back-stepped to 2009f and no change. httpd error log (no php error logging is done even though it is turned on in /etc/php.ini) -- date.timezone = "UTC" and is ignored and the /etc/sysconf/clock file OR date_default_timezone_set() function (most likely, since removing the file gives the old system date) is used by php instead: "PHP Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in Unknown on line 0 "PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0" /etc/localtime is a copy of the file for MDT and it shows up for OS time and nothing else. googling reveals that this same error keeps popping up in new php versions as if the original tz scripts get re-used each time without any updating until the same problem emerges after release. then the patch is made and the original scripts remain unchanged. Reproduce code: --- core startup crash -- Edit this bug report at http://bugs.php.net/?id=48882&edit=1
#48882 [Com]: "PHP Startup: Timezone database is corrupt"
ID: 48882 Comment by: bug dot odesk at gmail dot com Reported By: vonpreussen at 2secure dot us Status: No Feedback Bug Type: Date/time related Operating System: centos 5 PHP Version: 5.3.0 New Comment: CentOS 5, php 5.3 cli. tzdata 2009i. $ php -v PHP Strict Standards: PHP Startup: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead in Unknown on line 0 PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 Segmentation fault strace log. http://pastebin.com/f2b4d38c7 Previous Comments: [2009-07-18 01:00:01] 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". [2009-07-10 21:55:33] vonpreussen at 2secure dot us no. yum install. [2009-07-10 21:31:08] der...@php.net Did you compile PHP yourself? [2009-07-10 19:49:48] vonpreussen at 2secure dot us Description: updated php and it now fails every time over timezone issue. had latest tz data (tzdata-2009j) and back-stepped to 2009f and no change. httpd error log (no php error logging is done even though it is turned on in /etc/php.ini) -- date.timezone = "UTC" and is ignored and the /etc/sysconf/clock file OR date_default_timezone_set() function (most likely, since removing the file gives the old system date) is used by php instead: "PHP Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in Unknown on line 0 "PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0" /etc/localtime is a copy of the file for MDT and it shows up for OS time and nothing else. googling reveals that this same error keeps popping up in new php versions as if the original tz scripts get re-used each time without any updating until the same problem emerges after release. then the patch is made and the original scripts remain unchanged. Reproduce code: --- core startup crash -- Edit this bug report at http://bugs.php.net/?id=48882&edit=1
#49179 [NEW]: zero problem in if and switch
From: steve at ezd dot com
Operating system: linux
PHP version: 5.2.10
PHP Bug Type: *General Issues
Bug description: zero problem in if and switch
Description:
please run source code, it's self explained
it seems that when use 0 to compare with string, it returns true all the
time,
problem in if is when using ==, === has no problem
in switch case, it matches the first non number case
Reproduce code:
---
if (0=="a") echo "this is ture.";
$check=0;
switch ($check)
{
case 'a':
echo "this is a ";
break;
default :
echo "no match";
}
Expected result:
no match
Actual result:
--
this is ture.this is a
--
Edit bug report at http://bugs.php.net/?id=49179&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49179&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49179&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49179&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49179&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49179&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49179&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49179&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49179&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49179&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49179&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49179&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49179&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49179&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49179&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49179&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49179&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49179&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49179&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49179&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49179&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49179&r=mysqlcfg
#49122 [Opn]: undefined reference to mysqlnd_stmt_next_result on compile with --with-mysqli
ID: 49122 User updated by: gabrycucciolo84pv at fastwebnet dot it Reported By: gabrycucciolo84pv at fastwebnet dot it Status: Open Bug Type: MySQL related Operating System: Centos 4 PHP Version: 5.3, 6 (2009-08-04) Assigned To: andrey New Comment: fresh sources you mean latest cvn snapshot? Previous Comments: [2009-08-06 14:06:08] gabrycucciolo84pv at fastwebnet dot it It does not even start stating that it can't find mysql installation and to reinstall it. With 5.2.10 everything works like a charm... [2009-08-06 09:00:47] j...@php.net Please use fresh sources and preferrably build outside source tree. "make clean" after configure with different options might help too.. [2009-08-05 22:39:34] gabrycucciolo84pv at fastwebnet dot it /usr/bin/ld: warning: libcrypto.so.4, needed by /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../libpq.so, may conflict with libcrypto.so.0.9.8 ext/mysqli/.libs/mysqli_api.o(.text+0x304a): In function `zif_mysqli_stmt_more_results': /root/php-5.3.0/ext/mysqli/mysqli_api.c:1500: undefined reference to `mysqlnd_stmt_more_results' ext/mysqli/.libs/mysqli_api.o(.text+0x30da): In function `zif_mysqli_stmt_next_result': /root/php-5.3.0/ext/mysqli/mysqli_api.c:1516: undefined reference to `mysqlnd_stmt_more_results' ext/mysqli/.libs/mysqli_api.o(.text+0x30ef):/root/php-5.3.0/ext/mysqli/mysqli_api.c:1522: undefined reference to `mysqlnd_stmt_next_result' ext/pgsql/.libs/pgsql.o(.text+0x16d): In function `_php_pgsql_notice_handler': /root/php-5.3.0/ext/pgsql/pgsql.c:815: undefined reference to `ts_resource_ex' ext/pgsql/.libs/pgsql.o(.text+0x886): In function `zm_deactivate_pgsql': /root/php-5.3.0/ext/pgsql/pgsql.c:1036: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xeb9): In function `php_pgsql_do_connect': /root/php-5.3.0/ext/pgsql/pgsql.c:1261: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xf72):/root/php-5.3.0/ext/pgsql/pgsql.c:1218: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xfee):/root/php-5.3.0/ext/pgsql/pgsql.c:1235: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x1105):/root/php-5.3.0/ext/pgsql/pgsql.c:1134: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x11e7):/root/php-5.3.0/ext/pgsql/pgsql.c:1165: more undefined references to `executor_globals_id' follow ext/pgsql/.libs/pgsql.o(.text+0x40aa): In function `php_pgsql_fetch_hash': /root/php-5.3.0/ext/pgsql/pgsql.c:2498: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x433e):/root/php-5.3.0/ext/pgsql/pgsql.c:2564: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x59c3): In function `zif_pg_lo_import': /root/php-5.3.0/ext/pgsql/pgsql.c:3338: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x5d51): In function `zif_pg_lo_export': /root/php-5.3.0/ext/pgsql/pgsql.c:3475: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xc844): In function `php_pgsql_result2array': /root/php-5.3.0/ext/pgsql/pgsql.c:6199: undefined reference to `core_globals_id' ext/standard/.libs/info.o(.text+0xd): In function `php_info_write_wrapper': /root/php-5.3.0/ext/standard/info.c:80: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0x119): In function `php_print_gpcse_array': /root/php-5.3.0/ext/standard/info.c:149: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x8d2): In function `php_info_print_table_header': /root/php-5.3.0/ext/standard/info.c:1071: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0xa92): In function `php_info_print_table_row_internal': /root/php-5.3.0/ext/standard/info.c:1115: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0x1298): In function `php_print_info': /root/php-5.3.0/ext/standard/info.c:939: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x12d9):/root/php-5.3.0/ext/standard/info.c:942: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x131a):/root/php-5.3.0/ext/standard/info.c:945: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x135b):/root/php-5.3.0/ext/standard/info.c:948: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x1caf):/root/php-5.3.0/ext/standard/info.c:870: undefined reference to `sapi_globals_id' ext/standard/.libs/info.o(.text+0x1eae):/root/php-5.3.0/ext/standard/info.c:644: undefined reference to `sapi_globals_id' ext/standard/.libs/info.o(.text+0x22b4):/root/php-5.3.0/ext/standard/info.c:849: undefined reference to `sapi_globals_id' ext/mysqlnd/.libs/mysqlnd.o(.text+0xbf3): In
#49122 [Fbk->Opn]: undefined reference to mysqlnd_stmt_next_result on compile with --with-mysqli
ID: 49122 User updated by: gabrycucciolo84pv at fastwebnet dot it Reported By: gabrycucciolo84pv at fastwebnet dot it -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Centos 4 PHP Version: 5.3, 6 (2009-08-04) Assigned To: andrey New Comment: It does not even start stating that it can't find mysql installation and to reinstall it. With 5.2.10 everything works like a charm... Previous Comments: [2009-08-06 09:00:47] j...@php.net Please use fresh sources and preferrably build outside source tree. "make clean" after configure with different options might help too.. [2009-08-05 22:39:34] gabrycucciolo84pv at fastwebnet dot it /usr/bin/ld: warning: libcrypto.so.4, needed by /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../libpq.so, may conflict with libcrypto.so.0.9.8 ext/mysqli/.libs/mysqli_api.o(.text+0x304a): In function `zif_mysqli_stmt_more_results': /root/php-5.3.0/ext/mysqli/mysqli_api.c:1500: undefined reference to `mysqlnd_stmt_more_results' ext/mysqli/.libs/mysqli_api.o(.text+0x30da): In function `zif_mysqli_stmt_next_result': /root/php-5.3.0/ext/mysqli/mysqli_api.c:1516: undefined reference to `mysqlnd_stmt_more_results' ext/mysqli/.libs/mysqli_api.o(.text+0x30ef):/root/php-5.3.0/ext/mysqli/mysqli_api.c:1522: undefined reference to `mysqlnd_stmt_next_result' ext/pgsql/.libs/pgsql.o(.text+0x16d): In function `_php_pgsql_notice_handler': /root/php-5.3.0/ext/pgsql/pgsql.c:815: undefined reference to `ts_resource_ex' ext/pgsql/.libs/pgsql.o(.text+0x886): In function `zm_deactivate_pgsql': /root/php-5.3.0/ext/pgsql/pgsql.c:1036: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xeb9): In function `php_pgsql_do_connect': /root/php-5.3.0/ext/pgsql/pgsql.c:1261: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xf72):/root/php-5.3.0/ext/pgsql/pgsql.c:1218: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xfee):/root/php-5.3.0/ext/pgsql/pgsql.c:1235: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x1105):/root/php-5.3.0/ext/pgsql/pgsql.c:1134: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x11e7):/root/php-5.3.0/ext/pgsql/pgsql.c:1165: more undefined references to `executor_globals_id' follow ext/pgsql/.libs/pgsql.o(.text+0x40aa): In function `php_pgsql_fetch_hash': /root/php-5.3.0/ext/pgsql/pgsql.c:2498: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x433e):/root/php-5.3.0/ext/pgsql/pgsql.c:2564: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x59c3): In function `zif_pg_lo_import': /root/php-5.3.0/ext/pgsql/pgsql.c:3338: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x5d51): In function `zif_pg_lo_export': /root/php-5.3.0/ext/pgsql/pgsql.c:3475: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xc844): In function `php_pgsql_result2array': /root/php-5.3.0/ext/pgsql/pgsql.c:6199: undefined reference to `core_globals_id' ext/standard/.libs/info.o(.text+0xd): In function `php_info_write_wrapper': /root/php-5.3.0/ext/standard/info.c:80: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0x119): In function `php_print_gpcse_array': /root/php-5.3.0/ext/standard/info.c:149: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x8d2): In function `php_info_print_table_header': /root/php-5.3.0/ext/standard/info.c:1071: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0xa92): In function `php_info_print_table_row_internal': /root/php-5.3.0/ext/standard/info.c:1115: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0x1298): In function `php_print_info': /root/php-5.3.0/ext/standard/info.c:939: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x12d9):/root/php-5.3.0/ext/standard/info.c:942: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x131a):/root/php-5.3.0/ext/standard/info.c:945: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x135b):/root/php-5.3.0/ext/standard/info.c:948: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x1caf):/root/php-5.3.0/ext/standard/info.c:870: undefined reference to `sapi_globals_id' ext/standard/.libs/info.o(.text+0x1eae):/root/php-5.3.0/ext/standard/info.c:644: undefined reference to `sapi_globals_id' ext/standard/.libs/info.o(.text+0x22b4):/root/php-5.3.0/ext/standard/info.c:849: undefined reference to `sapi_globals_id' ext/mysqlnd/.libs/mysqlnd.o(.text+0xbf3): In function `_mysqlnd_restart_psession': /root/php-5.3.0/ext/mysqlnd/mysqlnd.c:442: undefined reference to `tsrm_mutex_lock' ext/mysqlnd/.libs/mysqlnd.o(.te
#48824 [Opn->Bgs]: dateTime->add() doesn't properly account for days past the end of months
ID: 48824
Updated by: j...@php.net
Reported By: brad at omnis dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux (CentOS 5.3)
PHP Version: 5.3.0
New Comment:
DateInterval uses the same parser as strtotime().
Previous Comments:
[2009-07-07 16:56:59] brad at omnis dot com
>From a brief reading of the source code, dateTime->add() doesn't
*appear* use the underlying strtotime library, so I don't see why this
function should be forced to have the same weakness of that function.
IMO, these date functions would be far more useful if they adhere to
common date manipulation ideals instead of using simple math as they are
currently doing.
As it stands now, the dateTime->add() function cannot be relied upon
for any sort of accounting math and IMO completely defeats the purpose
of specialized dateTime functions.
[2009-07-07 09:50:48] sjoerd-php at linuxonly dot nl
Thank you for your report.
The issue you report is not a bug. See also bug #43999.
[2009-07-06 22:24:39] brad at omnis dot com
Description:
dateTime->add(dateInterval) isn't applying proper calendar math when
adding intervals.
Reproduce code:
---
$dateTest = new dateTime('2008-01-31',new dateTimeZone("GMT"));
print_r($dateTest);
$dateTest->add(new dateInterval('P1M'));
print_r($dateTest);
Expected result:
DateTime Object
(
[date] => 2008-01-31 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
DateTime Object
(
[date] => 2008-02-28 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
Actual result:
--
DateTime Object
(
[date] => 2008-01-31 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
DateTime Object
(
[date] => 2008-03-02 00:00:00
[timezone_type] => 3
[timezone] => UTC
)
--
Edit this bug report at http://bugs.php.net/?id=48824&edit=1
#49153 [Opn->Bgs]: combining characters in UTF-8 doesn't seem to work
ID: 49153
Updated by: j...@php.net
Reported By: andy at bdnews24 dot com
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Win Server 2003 Enterprise SP2
PHP Version: 5.2.10
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #34670
Previous Comments:
[2009-08-04 14:05:41] andy at bdnews24 dot com
Description:
Using imagettftext some Bengali unicode text that combines characters
(uses diacritics) doesn't render properly: it displays too many
characters. Maybe the same as this (ancient) post:
http://www.mail-archive.com/php-gene...@lists.php.net/msg78902.html. I'm
afraid I can't find a free unicode Bengali font - I used MS Arial
Unicode. I've made a zip file with a screenshot and the repro code (in
case the UTF-8 string literal screws up on the way to your database;)
that's available at http://cl-t199-020cl.privatedns.com/repro.zip.
Reproduce code:
---
");
echo("");
?>
Expected result:
I expect to see two copies of the same text. The top copy is text
rendered by the browser, the bottom copy is a gif file.
Actual result:
--
The browser-rendered text displays correctly, the gif file is different
and incorrect.
--
Edit this bug report at http://bugs.php.net/?id=49153&edit=1
#49152 [Bgs]: Additional value $_SERVER
ID: 49152 User updated by: ruediger dot severit at de dot bertrandt dot com Reported By: ruediger dot severit at de dot bertrandt dot com Status: Bogus Bug Type: Feature/Change Request Operating System: XP PHP Version: 5.3.0 New Comment: Thank you. can be closed Previous Comments: [2009-08-04 17:42:37] scott...@php.net See the __LINE__ constant and you'll also find __FILE__ and __DIR__ [2009-08-04 13:13:24] ruediger dot severit at de dot bertrandt dot com Description: It would be nice to have an additional element in the $_SERVER variable which shows the actual line within the script where the command is placed: e.g: SOURCE: print "Debug line $_SERVER['script_line']: $to_be_debugged"; OUTPUT: Debug line 53: Hello Reproduce code: --- see description Expected result: see description Actual result: -- see description -- Edit this bug report at http://bugs.php.net/?id=49152&edit=1
#49177 [Opn->Ver]: include() causes strict erros when including overloading methods (PHP_5_2 only!)
ID: 49177 Updated by: j...@php.net -Summary: include() causes strict erros when including overloading methods Reported By: ss at zornig dot dk -Status: Open +Status: Verified Bug Type: Scripting Engine problem -Operating System: FreeBSD +Operating System: * -PHP Version: 5.2.10 +PHP Version: 5.2 (SVN-2009-08-05) Previous Comments: [2009-08-06 12:03:08] ss at zornig dot dk Description: When overloading a method, changing a parameter to accept a default value E_STRICT error is triggered. This however only happens if the object declaration is loading using include, not if the declaration is in the file called. Reproduce code: --- test.php: obj.php: Expected result: This should be without any errors as i would if the test.php looks like this: Actual result: -- Strict Standards: Declaration of ObjChild::set() should be compatible with that of ObjParent::set() in /home/webroot/dumpsite/obj.php on line 8 -- Edit this bug report at http://bugs.php.net/?id=49177&edit=1
#49178 [Opn->Fbk]: Incomplete file downloads
ID: 49178
Updated by: j...@php.net
Reported By: moricio at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: cURL related
Operating System: Windows 2003 Server SP2
PHP Version: 5.2.10
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-08-06 12:21:03] moricio at gmail dot com
Description:
Hi.
I have a PHP app where I generate a PDF file, using jasperreports, and
then mail this file to a subscriber. I use curl and the CURLOPT_FILE
option to get the pdf file. As soon as I finish getting the file, it
reports a size that is always an exact multiple of 4Kbytes, even when
the file is bigger than what PHP reports.
Reproduce code:
---
Code with error is ...
--
http://www.google.com";);
$tmpfname = tempnam(sys_get_temp_dir(), "IPV");
$fpOutput = fopen($tmpfname, "wb");
curl_setopt($ch, CURLOPT_FILE, $fpOutput);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_exec($ch);
curl_close($ch);
fclose($fpOutput);
echo "filesize: $tmpfname: " . filesize($tmpfname) . "\n";
?>
--
Code without error is ...
--
http://www.google.com";);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_WRITEFUNCTION, 'read_body');
curl_exec($ch);
curl_close($ch);
fclose($fpOutput);
echo "filesize: $tmpfname: " . filesize($tmpfname) . "\n";
die();
function read_body($ch, $string)
{
global $fpOutput;
$length = strlen($string);
if (fwrite($fpOutput, $string) === FALSE) {
echo "Cannot write to file";
die();
}
return $length;
}
?>
Expected result:
The second piece of code reported in this bug report gives the correct
file size.
The first piece of code saves the file with the correct size but
doesn't
report it correctly.
This was not happening until I upgraded to PHP 5.2.10 from a previous
version that I don't remember. :(
Hope you can find inside what is going on.
Best regards and thanks for a great piece of software.
Mauricio Ramirez
Actual result:
--
The first piece of code reports 4096 bytes for the google.com page.
The second piece of code reports (today!) 6672 bytes which is the right
size.
--
Edit this bug report at http://bugs.php.net/?id=49178&edit=1
#49178 [NEW]: Incomplete file downloads
From: moricio at gmail dot com
Operating system: Windows 2003 Server SP2
PHP version: 5.2.10
PHP Bug Type: cURL related
Bug description: Incomplete file downloads
Description:
Hi.
I have a PHP app where I generate a PDF file, using jasperreports, and
then mail this file to a subscriber. I use curl and the CURLOPT_FILE
option to get the pdf file. As soon as I finish getting the file, it
reports a size that is always an exact multiple of 4Kbytes, even when
the file is bigger than what PHP reports.
Reproduce code:
---
Code with error is ...
--
http://www.google.com";);
$tmpfname = tempnam(sys_get_temp_dir(), "IPV");
$fpOutput = fopen($tmpfname, "wb");
curl_setopt($ch, CURLOPT_FILE, $fpOutput);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_exec($ch);
curl_close($ch);
fclose($fpOutput);
echo "filesize: $tmpfname: " . filesize($tmpfname) . "\n";
?>
--
Code without error is ...
--
http://www.google.com";);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_WRITEFUNCTION, 'read_body');
curl_exec($ch);
curl_close($ch);
fclose($fpOutput);
echo "filesize: $tmpfname: " . filesize($tmpfname) . "\n";
die();
function read_body($ch, $string)
{
global $fpOutput;
$length = strlen($string);
if (fwrite($fpOutput, $string) === FALSE) {
echo "Cannot write to file";
die();
}
return $length;
}
?>
Expected result:
The second piece of code reported in this bug report gives the correct
file size.
The first piece of code saves the file with the correct size but doesn't
report it correctly.
This was not happening until I upgraded to PHP 5.2.10 from a previous
version that I don't remember. :(
Hope you can find inside what is going on.
Best regards and thanks for a great piece of software.
Mauricio Ramirez
Actual result:
--
The first piece of code reports 4096 bytes for the google.com page.
The second piece of code reports (today!) 6672 bytes which is the right
size.
--
Edit bug report at http://bugs.php.net/?id=49178&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49178&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49178&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49178&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49178&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49178&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49178&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49178&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49178&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49178&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49178&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49178&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49178&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49178&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49178&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49178&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49178&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49178&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49178&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49178&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49178&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49178&r=mysqlcfg
#49177 [NEW]: include() causes strict erros when including overloading methods
From: ss at zornig dot dk Operating system: FreeBSD PHP version: 5.2.10 PHP Bug Type: Scripting Engine problem Bug description: include() causes strict erros when including overloading methods Description: When overloading a method, changing a parameter to accept a default value E_STRICT error is triggered. This however only happens if the object declaration is loading using include, not if the declaration is in the file called. Reproduce code: --- test.php: obj.php: Expected result: This should be without any errors as i would if the test.php looks like this: Actual result: -- Strict Standards: Declaration of ObjChild::set() should be compatible with that of ObjParent::set() in /home/webroot/dumpsite/obj.php on line 8 -- Edit bug report at http://bugs.php.net/?id=49177&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49177&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49177&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49177&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49177&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49177&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49177&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49177&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49177&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49177&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49177&r=support Expected behavior: http://bugs.php.net/fix.php?id=49177&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49177&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49177&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49177&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49177&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49177&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49177&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49177&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49177&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49177&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49177&r=mysqlcfg
#49176 [NEW]: get_declared_classes; Argument for namespace, default to \
From: robert dot de dot wilde at online dot nl Operating system: Linux PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: get_declared_classes; Argument for namespace, default to \ Description: It would be nice to have an additional argument (string, defaults to '\') to 'get_declared_classes' to only return the classes inside a certain namespace. An second argument (bool, defaults to false) could be optional to ask if resolution should be recursive to subnamespaces. Reproduce code: --- Would be something defined as being: get_declared_namespaces( String $sNamespace = '\', Bool $bRecursive = false); Expected result: List of classes in namespace. Actual result: -- List of all classes. -- Edit bug report at http://bugs.php.net/?id=49176&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49176&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49176&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49176&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49176&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49176&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49176&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49176&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49176&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49176&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49176&r=support Expected behavior: http://bugs.php.net/fix.php?id=49176&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49176&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49176&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49176&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49176&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49176&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49176&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49176&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49176&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49176&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49176&r=mysqlcfg
#49173 [Opn->Fbk]: Php don't work with mod_fcgid if I load a extension
ID: 49173 Updated by: j...@php.net Reported By: malina dot laszlo at malina dot hu -Status: Open +Status: Feedback Bug Type: Dynamic loading Operating System: Debian Lenny PHP Version: 5.3.0 Previous Comments: [2009-08-06 09:43:57] malina dot laszlo at malina dot hu Hi! I tried to compile the PHP (not snapshot, but release). There are two ways to do: 1. I am updating system libraries (libgd, libpng, etc) and compiling gd extension by shared (--with-gd=shared,/usr and png,jpg,xpm, freetype,etc by shared) 2. I compiling gd extension by "embedded" (it is not shared). (--with-gd [it is embedded for me] and png, jpg,xpm, etc is not shared) Results: Point 1: it is failed, same error Point 2: this is good, no error! I will try to compile snapshot-php5.3 by shared and "embedded". I'm curious :) [2009-08-06 08:57:47] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-06 08:07:09] malina dot laszlo at malina dot hu Hi! I am trying to load extensions and each works well except for the gd.so. If I load gd, server send me "Status 500" and written above logs. Before there was already a compiling problem (gdhelper), but this is no, without error compiled. Thanks for your help! Bearcheese [2009-08-06 00:31:26] malina dot laszlo at malina dot hu Description: Hello! I compiled php-5.3.0 (CGI), apache-2.2.12 (mpm-worker) and mod_fcgid-2.2.0 on Debian Lenny. I have more extension: mysql, mysqli, pdo, gd, gettext, memcache, imagick, idn, etc. When I give extension_dir (with absoluth path) and I does NOT allow to load extensions then no problem (and no extension). When I does allow to load only ONE extension (for example gd.so), then the server send me "Internal server error" (status 500). I can see in apache error-log: [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error. [info] (104)Connection reset by peer: mod_fcgid: can't read data from fcgid handler [warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request function What is problem? (Sorry for my bad English!) -- Edit this bug report at http://bugs.php.net/?id=49173&edit=1
#49173 [Fbk->Opn]: Php don't work with mod_fcgid if I load a extension
ID: 49173 User updated by: malina dot laszlo at malina dot hu Reported By: malina dot laszlo at malina dot hu -Status: Feedback +Status: Open Bug Type: Dynamic loading Operating System: Debian Lenny PHP Version: 5.3.0 New Comment: Hi! I tried to compile the PHP (not snapshot, but release). There are two ways to do: 1. I am updating system libraries (libgd, libpng, etc) and compiling gd extension by shared (--with-gd=shared,/usr and png,jpg,xpm, freetype,etc by shared) 2. I compiling gd extension by "embedded" (it is not shared). (--with-gd [it is embedded for me] and png, jpg,xpm, etc is not shared) Results: Point 1: it is failed, same error Point 2: this is good, no error! I will try to compile snapshot-php5.3 by shared and "embedded". I'm curious :) Previous Comments: [2009-08-06 08:57:47] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-06 08:07:09] malina dot laszlo at malina dot hu Hi! I am trying to load extensions and each works well except for the gd.so. If I load gd, server send me "Status 500" and written above logs. Before there was already a compiling problem (gdhelper), but this is no, without error compiled. Thanks for your help! Bearcheese [2009-08-06 00:31:26] malina dot laszlo at malina dot hu Description: Hello! I compiled php-5.3.0 (CGI), apache-2.2.12 (mpm-worker) and mod_fcgid-2.2.0 on Debian Lenny. I have more extension: mysql, mysqli, pdo, gd, gettext, memcache, imagick, idn, etc. When I give extension_dir (with absoluth path) and I does NOT allow to load extensions then no problem (and no extension). When I does allow to load only ONE extension (for example gd.so), then the server send me "Internal server error" (status 500). I can see in apache error-log: [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error. [info] (104)Connection reset by peer: mod_fcgid: can't read data from fcgid handler [warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request function What is problem? (Sorry for my bad English!) -- Edit this bug report at http://bugs.php.net/?id=49173&edit=1
#49122 [Opn->Fbk]: undefined reference to mysqlnd_stmt_next_result on compile with --with-mysqli
ID: 49122 Updated by: j...@php.net Reported By: gabrycucciolo84pv at fastwebnet dot it -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Centos 4 PHP Version: 5.3, 6 (2009-08-04) Assigned To: andrey New Comment: Please use fresh sources and preferrably build outside source tree. "make clean" after configure with different options might help too.. Previous Comments: [2009-08-05 22:39:34] gabrycucciolo84pv at fastwebnet dot it /usr/bin/ld: warning: libcrypto.so.4, needed by /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../libpq.so, may conflict with libcrypto.so.0.9.8 ext/mysqli/.libs/mysqli_api.o(.text+0x304a): In function `zif_mysqli_stmt_more_results': /root/php-5.3.0/ext/mysqli/mysqli_api.c:1500: undefined reference to `mysqlnd_stmt_more_results' ext/mysqli/.libs/mysqli_api.o(.text+0x30da): In function `zif_mysqli_stmt_next_result': /root/php-5.3.0/ext/mysqli/mysqli_api.c:1516: undefined reference to `mysqlnd_stmt_more_results' ext/mysqli/.libs/mysqli_api.o(.text+0x30ef):/root/php-5.3.0/ext/mysqli/mysqli_api.c:1522: undefined reference to `mysqlnd_stmt_next_result' ext/pgsql/.libs/pgsql.o(.text+0x16d): In function `_php_pgsql_notice_handler': /root/php-5.3.0/ext/pgsql/pgsql.c:815: undefined reference to `ts_resource_ex' ext/pgsql/.libs/pgsql.o(.text+0x886): In function `zm_deactivate_pgsql': /root/php-5.3.0/ext/pgsql/pgsql.c:1036: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xeb9): In function `php_pgsql_do_connect': /root/php-5.3.0/ext/pgsql/pgsql.c:1261: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xf72):/root/php-5.3.0/ext/pgsql/pgsql.c:1218: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xfee):/root/php-5.3.0/ext/pgsql/pgsql.c:1235: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x1105):/root/php-5.3.0/ext/pgsql/pgsql.c:1134: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x11e7):/root/php-5.3.0/ext/pgsql/pgsql.c:1165: more undefined references to `executor_globals_id' follow ext/pgsql/.libs/pgsql.o(.text+0x40aa): In function `php_pgsql_fetch_hash': /root/php-5.3.0/ext/pgsql/pgsql.c:2498: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x433e):/root/php-5.3.0/ext/pgsql/pgsql.c:2564: undefined reference to `executor_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x59c3): In function `zif_pg_lo_import': /root/php-5.3.0/ext/pgsql/pgsql.c:3338: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0x5d51): In function `zif_pg_lo_export': /root/php-5.3.0/ext/pgsql/pgsql.c:3475: undefined reference to `core_globals_id' ext/pgsql/.libs/pgsql.o(.text+0xc844): In function `php_pgsql_result2array': /root/php-5.3.0/ext/pgsql/pgsql.c:6199: undefined reference to `core_globals_id' ext/standard/.libs/info.o(.text+0xd): In function `php_info_write_wrapper': /root/php-5.3.0/ext/standard/info.c:80: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0x119): In function `php_print_gpcse_array': /root/php-5.3.0/ext/standard/info.c:149: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x8d2): In function `php_info_print_table_header': /root/php-5.3.0/ext/standard/info.c:1071: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0xa92): In function `php_info_print_table_row_internal': /root/php-5.3.0/ext/standard/info.c:1115: undefined reference to `ts_resource_ex' ext/standard/.libs/info.o(.text+0x1298): In function `php_print_info': /root/php-5.3.0/ext/standard/info.c:939: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x12d9):/root/php-5.3.0/ext/standard/info.c:942: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x131a):/root/php-5.3.0/ext/standard/info.c:945: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x135b):/root/php-5.3.0/ext/standard/info.c:948: undefined reference to `executor_globals_id' ext/standard/.libs/info.o(.text+0x1caf):/root/php-5.3.0/ext/standard/info.c:870: undefined reference to `sapi_globals_id' ext/standard/.libs/info.o(.text+0x1eae):/root/php-5.3.0/ext/standard/info.c:644: undefined reference to `sapi_globals_id' ext/standard/.libs/info.o(.text+0x22b4):/root/php-5.3.0/ext/standard/info.c:849: undefined reference to `sapi_globals_id' ext/mysqlnd/.libs/mysqlnd.o(.text+0xbf3): In function `_mysqlnd_restart_psession': /root/php-5.3.0/ext/mysqlnd/mysqlnd.c:442: undefined reference to `tsrm_mutex_lock' ext/mysqlnd/.libs/mysqlnd.o(.text+0xc12):/root/php-5.3.0/ext/mysqlnd/mysqlnd.c:442: undefined reference to `tsrm_mutex_unlock' ext/mysqlnd/.libs/mysqlnd.o(.text+0xcf2): In function `mysqlnd_send_close': /root/php-5.3.0/ext/mysqlnd/mysqlnd.c:1426: undefined reference to `tsrm_mutex_lock' ext/mysqlnd/.li
#49173 [Opn->Fbk]: Php don't work with mod_fcgid if I load a extension
ID: 49173 Updated by: j...@php.net Reported By: malina dot laszlo at malina dot hu -Status: Open +Status: Feedback Bug Type: Dynamic loading Operating System: Debian Lenny PHP Version: 5.3.0 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-08-06 08:07:09] malina dot laszlo at malina dot hu Hi! I am trying to load extensions and each works well except for the gd.so. If I load gd, server send me "Status 500" and written above logs. Before there was already a compiling problem (gdhelper), but this is no, without error compiled. Thanks for your help! Bearcheese [2009-08-06 00:31:26] malina dot laszlo at malina dot hu Description: Hello! I compiled php-5.3.0 (CGI), apache-2.2.12 (mpm-worker) and mod_fcgid-2.2.0 on Debian Lenny. I have more extension: mysql, mysqli, pdo, gd, gettext, memcache, imagick, idn, etc. When I give extension_dir (with absoluth path) and I does NOT allow to load extensions then no problem (and no extension). When I does allow to load only ONE extension (for example gd.so), then the server send me "Internal server error" (status 500). I can see in apache error-log: [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error. [info] (104)Connection reset by peer: mod_fcgid: can't read data from fcgid handler [warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request function What is problem? (Sorry for my bad English!) -- Edit this bug report at http://bugs.php.net/?id=49173&edit=1
#49173 [Opn]: Php don't work with mod_fcgid if I load a extension
ID: 49173 User updated by: malina dot laszlo at malina dot hu Reported By: malina dot laszlo at malina dot hu Status: Open Bug Type: Dynamic loading Operating System: Debian Lenny PHP Version: 5.3.0 New Comment: Hi! I am trying to load extensions and each works well except for the gd.so. If I load gd, server send me "Status 500" and written above logs. Before there was already a compiling problem (gdhelper), but this is no, without error compiled. Thanks for your help! Bearcheese Previous Comments: [2009-08-06 00:31:26] malina dot laszlo at malina dot hu Description: Hello! I compiled php-5.3.0 (CGI), apache-2.2.12 (mpm-worker) and mod_fcgid-2.2.0 on Debian Lenny. I have more extension: mysql, mysqli, pdo, gd, gettext, memcache, imagick, idn, etc. When I give extension_dir (with absoluth path) and I does NOT allow to load extensions then no problem (and no extension). When I does allow to load only ONE extension (for example gd.so), then the server send me "Internal server error" (status 500). I can see in apache error-log: [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error. [info] (104)Connection reset by peer: mod_fcgid: can't read data from fcgid handler [warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request function What is problem? (Sorry for my bad English!) -- Edit this bug report at http://bugs.php.net/?id=49173&edit=1
