[PHP-BUG] Bug #61023 [NEW]: Wrong sorting in strnatcasecmp for cyrillic letters
From: Operating system: FreeBSD 6.x-8.x PHP version: 5.3.10 Package: Strings related Bug Type: Bug Bug description:Wrong sorting in strnatcasecmp for cyrillic letters Description: The strnatcasecmp function wrongly sorts strings in Russian, putting all uppercase letters before lowercase letters. Test script: --- Expected result: 1 -1 1 -1 Actual result: -- 1 -1 1 1 -- Edit bug report at https://bugs.php.net/bug.php?id=61023&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61023&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61023&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61023&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61023&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61023&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61023&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61023&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61023&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61023&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61023&r=support Expected behavior: https://bugs.php.net/fix.php?id=61023&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61023&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61023&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61023&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61023&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61023&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61023&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61023&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61023&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61023&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61023&r=mysqlcfg
Bug #61023 [Opn->Nab]: Wrong sorting in strnatcasecmp for cyrillic letters
Edit report at https://bugs.php.net/bug.php?id=61023&edit=1 ID: 61023 Updated by: cataphr...@php.net Reported by:redrat at mail dot ru Summary:Wrong sorting in strnatcasecmp for cyrillic letters -Status: Open +Status: Not a bug Type: Bug Package:Strings related Operating System: FreeBSD 6.x-8.x PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I'm afraid the strnat* functions don't support any sort of localization. Take a look at functions that are locale-dependent like strcoll or ICU collators (intl extension). Previous Comments: [2012-02-09 08:01:56] redrat at mail dot ru Description: The strnatcasecmp function wrongly sorts strings in Russian, putting all uppercase letters before lowercase letters. Test script: --- Expected result: 1 -1 1 -1 Actual result: -- 1 -1 1 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=61023&edit=1
Bug #61012 [Nab]: filter_var don't pass valid email address
Edit report at https://bugs.php.net/bug.php?id=61012&edit=1
ID: 61012
User updated by:sucotronic at gmail dot com
Reported by:sucotronic at gmail dot com
Summary:filter_var don't pass valid email address
Status: Not a bug
Type: Bug
Package:Mail related
Operating System: linux ubuntu 10.04
PHP Version:5.3SVN-2012-02-08 (snap)
Block user comment: N
Private report: N
New Comment:
Ok, I found it at: https://bugs.php.net/bug.php?id=49576 fixed in 5.3.3 release
and open a bug in ubuntu to request to update it
(https://bugs.launchpad.net/ubuntu/+source/php5/+bug/929387). Thanks for help.
Previous Comments:
[2012-02-08 18:58:20] ras...@php.net
Yes, this was fixed in July 2010 in 5.3.3.
[2012-02-08 18:12:10] anon at anon dot anon
I also get false, using PHP 5.3.2/Windows.
But according to the change log, FILTER_VALIDATE_EMAIL was overhauled in PHP
5.3.3, in July 2010, after this bug report:
https://bugs.php.net/bug.php?id=49576
[2012-02-08 17:55:28] sucotronic at gmail dot com
More exactly, my version is: 5.3.2-1ubuntu4.11
[2012-02-08 16:49:29] ras...@php.net
Unable to reproduce in 5.3/5.4:
php > echo filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL);
+4654651...@test.com
Make sure you are actually trying this in 5.3. This may have been broken in
5.2,
but was fixed years ago in 5.3.
[2012-02-08 14:58:45] sucotronic at gmail dot com
Description:
If you use the filter_var function to test an email address, and the address
starts with the '+' sign, it's marked as invalid, but it isn't.
Test script:
---
filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL)
Expected result:
Return the string and not false.
Actual result:
--
false
--
Edit this bug report at https://bugs.php.net/bug.php?id=61012&edit=1
[PHP-BUG] Req #61024 [NEW]: IPTC tags limited to 64 chars
From:
Operating system:
PHP version: Irrelevant
Package: GetImageSize related
Bug Type: Feature/Change Request
Bug description:IPTC tags limited to 64 chars
Description:
---
>From manual page:
http://www.php.net/function.iptcparse#refsect1-function.iptcparse-description
---
The code example below returns values in $desc truncated to 64 chars.
We would like to see that the full strings are returned.
Test script:
---
$attr = getimagesize($file, $info);
$iptc = iptcparse($info['APP13']);
foreach (array_keys($iptc) as $s) {
if ( is_array($iptc[$s]) ) {
$c = count ($iptc[$s]);
for ($i=0; $i <$c; $i++) {
$desc = $iptc[$s][$i];
echo $desc.'';
}
}
}
--
Edit bug report at https://bugs.php.net/bug.php?id=61024&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61024&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61024&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61024&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61024&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61024&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61024&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61024&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61024&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61024&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61024&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61024&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61024&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61024&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61024&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61024&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61024&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61024&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61024&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61024&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61024&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61024&r=mysqlcfg
[PHP-BUG] Bug #61025 [NEW]: __invoke() visibility not honored
From: Operating system: *nix PHP version: 5.3.10 Package: Class/Object related Bug Type: Bug Bug description:__invoke() visibility not honored Description: __invoke() visibility is not honored when indirectly called as $obj(). It is, when directly called, via $obj->__invoke(); Please, note as well that declaring __invoke() as static works as well, I think it shouldn't (nonsense) Test script: --- __invoke(); */ Expected result: Call to private method Bar::__invoke() from context ... Actual result: -- Bar -- Edit bug report at https://bugs.php.net/bug.php?id=61025&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61025&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61025&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61025&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61025&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61025&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61025&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61025&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61025&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61025&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61025&r=support Expected behavior: https://bugs.php.net/fix.php?id=61025&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61025&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61025&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61025&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61025&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61025&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61025&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61025&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61025&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61025&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61025&r=mysqlcfg
Bug #60232 [Com]: Wrong lock support detection for streams
Edit report at https://bugs.php.net/bug.php?id=60232&edit=1
ID: 60232
Comment by: karsten at typo3 dot org
Reported by:goetas at lignano dot it
Summary:Wrong lock support detection for streams
Status: Not a bug
Type: Bug
Package:Streams related
Operating System: ubuntu
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I have just been bitten by this issue, and for all I can tell the reasoning
behind what goetas writes makes me think "yeah, right!".
Could someone *please* reevaluate the "not a bug" statements?
Previous Comments:
[2011-11-29 15:15:07] goetas at lignano dot it
This is extracted from standard/file.c starting from line 618.
I have commented some fundamental parts for this bug.
...
} else if (flags & LOCK_EX) { // exclusive lock?
// the following lines does not check any real stream locking support
// this code will block all protocols
// that use LOCK_EX, except file://
// are we using a stream protocol? eg: file:// http:// custom://
if (php_memnstr(filename, "://", sizeof("://") - 1, filename + filename_len))
{
// if the protocol is not file:// throw an error
if (strncasecmp(filename, "file://", sizeof("file://") - 1)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Exclusive locks may only be set for regular files");
RETURN_FALSE;
}
}
mode[0] = 'c';
}
// the following lines can not be reached by any other
//protocol using LOCK_EX, except file://
mode[2] = '\0';
stream = php_stream_open_wrapper_ex(filename, mode, ((flags &
PHP_FILE_USE_INCLUDE_PATH) ? USE_PATH : 0) | ENFORCE_SAFE_MODE | REPORT_ERRORS,
NULL, context);
if (stream == NULL) {
RETURN_FALSE;
}
// better locking check
if (flags & LOCK_EX && (!php_stream_supports_lock(stream) ||
php_stream_lock(stream, LOCK_EX))) {
php_stream_close(stream);
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Exclusive locks are not
supported for this stream");
RETURN_FALSE;
}
According to current implementation of file_put_contents there is no way to use
exclusive locks support with a custom protocol wrapper.
[2011-11-29 13:30:09] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The stream_support_locking() merely checks if stream->fd is present, it does
not
"actually" check if locking is supported. Therefor the check is actually
correct.
[2011-11-16 19:26:12] goetas at lignano dot it
in file.c there is a double check for stream locking support, but the first
check is done in the worong way.
i'm not a c programmer, i think that should be done somethink like this
if(file_lock) then
if(is_stream && !stream_support_locking) then
throw error
endif
endif
[2011-11-16 12:32:17] fel...@php.net
The first check was introduced to fix the issue reported in bug #44501.
[2011-11-07 12:04:03] goetas at lignano dot it
Description:
I have implemented my own stream that support locking (defined the function
stream_lock).
when use:
file_put_contents("sqlfile://www.pppoa.it/x", "", LOCK_EX);
I get this error: Exclusive locks may only be set for regular files
I've take a look into PHP_5_3/ext/standard/file.c, and at line 620 there is a
check, that generates this error.
Few lines after, at line 635 there is a second check, for stream lock support.
But these lines of code (635...) is newer reachable because all operations on
stream that require locking will stop on line 623.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60232&edit=1
Bug #61020 [Com]: Security risk from find usage recommendation
Edit report at https://bugs.php.net/bug.php?id=61020&edit=1
ID: 61020
Comment by: chortos at inbox dot lv
Reported by:ond...@php.net
Summary:Security risk from find usage recommendation
Status: Open
Type: Bug
Package:*Configuration Issues
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
find on OS X does support -execdir.
Previous Comments:
[2012-02-09 01:13:40] ahar...@php.net
One problem with all of the options here is that they're a fair way from POSIX
compliant -- fuser on OS X doesn't support -s, for instance, nor does find
support -execdir. Solaris find doesn't even support -delete or -print0.
Obviously this is less of an issue in Debian. :)
Given the (pretty severe) restrictions if we want to cover all of the non-
Windows platforms PHP runs on, do we even want to recommend a one-liner in
php.ini? Maybe it would be better to come up with a short, portable shell
script
and include it in the session reference in the manual and link to that.
[2012-02-09 00:41:43] ond...@php.net
s/most error-prone/least error-prone/
[2012-02-09 00:31:44] ond...@php.net
And if you cannot use find with -delete or -execdir at least do:
find /path/to/sessions -mindepth 1 -maxdepth 1 -cmin +24 -execdir rm "{}" \;
[2012-02-09 00:29:10] ond...@php.net
Description:
; NOTE: If you are using the subdirectory option for storing session files
[...]
; find /path/to/sessions -cmin +24 | xargs rm
because it is prone to '\n' attack. You can see the security
considerations of GNU find.
Much better would be:
find /path/to/sessions -cmin +24 -delete
or at least
find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find)
The most error-prone way is something we cooked up in Debian:
find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f
-ignore_readdir_race -cmin +24 ! -execdir fuser -s {} 2>/dev/null \;
-delete
which depends on fuser at least version 22.15 (which has removed
fork() call which was able to swamp up whole system with zombies).
The fuser call checks if the session file is still in use, because the
script was deleting still active sessions opened 24+ mins ago.
Test script:
---
Race condition for -exec rm {} \;:
while true; do
mkdir /var/lib/php5/blah
touch /var/lib/php5/blah/passwd
rmdir /var/lib/php5/blah
ln -s /etc /var/lib/php5/blah
done
xargs attack:
ondrej@howl:/tmp/php_sess$ touch bar
ondrej@howl:/tmp/php_sess$ touch -t 20120101 "$(echo -e 'foo\nbar')"
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Feb 9 01:26 bar
-rw-r--r-- 1 ondrej ondrej 0 Jan 1 00:00 foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24
/tmp/php_sess/foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 | xargs rm
rm: cannot remove `/tmp/php_sess/foo': No such file or directory
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Jan 1 00:00 foo?bar
--
Edit this bug report at https://bugs.php.net/bug.php?id=61020&edit=1
Bug #61020 [Opn]: Security risk from find usage recommendation
Edit report at https://bugs.php.net/bug.php?id=61020&edit=1
ID: 61020
User updated by:ond...@php.net
Reported by:ond...@php.net
Summary:Security risk from find usage recommendation
Status: Open
Type: Bug
Package:*Configuration Issues
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
Quick & dirty would be to recommend using find using -delete and recommending
to
install GNU find on platforms where -delete is not supported.
e.g replace current line with:
; find /path/to/sessions -mindepth 1 -maxdepth 1 -cmin +24 -delete
;
; If your find does not support -delete option, we recommend installing
; and using GNU find which does support this option.
'fuser -s' can be replaced by 'fuser >/dev/null', but it is not really needed,
but it's very convenient for long sessions (like editing page in mediawiki).
Anyway workaround exists here - just increase gc_maxlifetime.
Previous Comments:
[2012-02-09 09:43:03] chortos at inbox dot lv
find on OS X does support -execdir.
[2012-02-09 01:13:40] ahar...@php.net
One problem with all of the options here is that they're a fair way from POSIX
compliant -- fuser on OS X doesn't support -s, for instance, nor does find
support -execdir. Solaris find doesn't even support -delete or -print0.
Obviously this is less of an issue in Debian. :)
Given the (pretty severe) restrictions if we want to cover all of the non-
Windows platforms PHP runs on, do we even want to recommend a one-liner in
php.ini? Maybe it would be better to come up with a short, portable shell
script
and include it in the session reference in the manual and link to that.
[2012-02-09 00:41:43] ond...@php.net
s/most error-prone/least error-prone/
[2012-02-09 00:31:44] ond...@php.net
And if you cannot use find with -delete or -execdir at least do:
find /path/to/sessions -mindepth 1 -maxdepth 1 -cmin +24 -execdir rm "{}" \;
[2012-02-09 00:29:10] ond...@php.net
Description:
; NOTE: If you are using the subdirectory option for storing session files
[...]
; find /path/to/sessions -cmin +24 | xargs rm
because it is prone to '\n' attack. You can see the security
considerations of GNU find.
Much better would be:
find /path/to/sessions -cmin +24 -delete
or at least
find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find)
The most error-prone way is something we cooked up in Debian:
find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f
-ignore_readdir_race -cmin +24 ! -execdir fuser -s {} 2>/dev/null \;
-delete
which depends on fuser at least version 22.15 (which has removed
fork() call which was able to swamp up whole system with zombies).
The fuser call checks if the session file is still in use, because the
script was deleting still active sessions opened 24+ mins ago.
Test script:
---
Race condition for -exec rm {} \;:
while true; do
mkdir /var/lib/php5/blah
touch /var/lib/php5/blah/passwd
rmdir /var/lib/php5/blah
ln -s /etc /var/lib/php5/blah
done
xargs attack:
ondrej@howl:/tmp/php_sess$ touch bar
ondrej@howl:/tmp/php_sess$ touch -t 20120101 "$(echo -e 'foo\nbar')"
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Feb 9 01:26 bar
-rw-r--r-- 1 ondrej ondrej 0 Jan 1 00:00 foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24
/tmp/php_sess/foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 | xargs rm
rm: cannot remove `/tmp/php_sess/foo': No such file or directory
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Jan 1 00:00 foo?bar
--
Edit this bug report at https://bugs.php.net/bug.php?id=61020&edit=1
[PHP-BUG] Bug #61026 [NEW]: Separate pools on same port
From: Operating system: Debain Squeeze x64 PHP version: 5.3.10 Package: FPM related Bug Type: Bug Bug description:Separate pools on same port Description: It's maybe a feature, but if I define two pools and accidentally set them to listen on the same address/ports and I do a multiple file upload, some of the files will be handled by pool X, some others by pool Y. Hence their users will be mixed too. user = X listen = 127.0.0.1:9000 user = Y listen = 127.0.0.1:9000 Test script: --- - Expected result: Php fpm should warn about using two pools with the same listen directive. Actual result: -- - -- Edit bug report at https://bugs.php.net/bug.php?id=61026&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61026&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61026&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61026&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61026&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61026&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61026&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61026&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61026&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61026&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61026&r=support Expected behavior: https://bugs.php.net/fix.php?id=61026&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61026&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61026&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61026&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61026&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61026&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61026&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61026&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61026&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61026&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61026&r=mysqlcfg
Bug #61023 [Com]: Wrong sorting in strnatcasecmp for cyrillic letters
Edit report at https://bugs.php.net/bug.php?id=61023&edit=1 ID: 61023 Comment by: redrat at mail dot ru Reported by:redrat at mail dot ru Summary:Wrong sorting in strnatcasecmp for cyrillic letters Status: Not a bug Type: Bug Package:Strings related Operating System: FreeBSD 6.x-8.x PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Oh, I see... Well, there is some another methods around here to play with. Previous Comments: [2012-02-09 08:40:26] cataphr...@php.net I'm afraid the strnat* functions don't support any sort of localization. Take a look at functions that are locale-dependent like strcoll or ICU collators (intl extension). [2012-02-09 08:01:56] redrat at mail dot ru Description: The strnatcasecmp function wrongly sorts strings in Russian, putting all uppercase letters before lowercase letters. Test script: --- Expected result: 1 -1 1 -1 Actual result: -- 1 -1 1 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=61023&edit=1
Bug #60232 [Nab]: Wrong lock support detection for streams
Edit report at https://bugs.php.net/bug.php?id=60232&edit=1
ID: 60232
User updated by:goetas at lignano dot it
Reported by:goetas at lignano dot it
Summary:Wrong lock support detection for streams
Status: Not a bug
Type: Bug
Package:Streams related
Operating System: ubuntu
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
+1!
i'm right with you!
Previous Comments:
[2012-02-09 09:25:36] karsten at typo3 dot org
I have just been bitten by this issue, and for all I can tell the reasoning
behind what goetas writes makes me think "yeah, right!".
Could someone *please* reevaluate the "not a bug" statements?
[2011-11-29 15:15:07] goetas at lignano dot it
This is extracted from standard/file.c starting from line 618.
I have commented some fundamental parts for this bug.
...
} else if (flags & LOCK_EX) { // exclusive lock?
// the following lines does not check any real stream locking support
// this code will block all protocols
// that use LOCK_EX, except file://
// are we using a stream protocol? eg: file:// http:// custom://
if (php_memnstr(filename, "://", sizeof("://") - 1, filename + filename_len))
{
// if the protocol is not file:// throw an error
if (strncasecmp(filename, "file://", sizeof("file://") - 1)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Exclusive locks may only be set for regular files");
RETURN_FALSE;
}
}
mode[0] = 'c';
}
// the following lines can not be reached by any other
//protocol using LOCK_EX, except file://
mode[2] = '\0';
stream = php_stream_open_wrapper_ex(filename, mode, ((flags &
PHP_FILE_USE_INCLUDE_PATH) ? USE_PATH : 0) | ENFORCE_SAFE_MODE | REPORT_ERRORS,
NULL, context);
if (stream == NULL) {
RETURN_FALSE;
}
// better locking check
if (flags & LOCK_EX && (!php_stream_supports_lock(stream) ||
php_stream_lock(stream, LOCK_EX))) {
php_stream_close(stream);
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Exclusive locks are not
supported for this stream");
RETURN_FALSE;
}
According to current implementation of file_put_contents there is no way to use
exclusive locks support with a custom protocol wrapper.
[2011-11-29 13:30:09] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The stream_support_locking() merely checks if stream->fd is present, it does
not
"actually" check if locking is supported. Therefor the check is actually
correct.
[2011-11-16 19:26:12] goetas at lignano dot it
in file.c there is a double check for stream locking support, but the first
check is done in the worong way.
i'm not a c programmer, i think that should be done somethink like this
if(file_lock) then
if(is_stream && !stream_support_locking) then
throw error
endif
endif
[2011-11-16 12:32:17] fel...@php.net
The first check was introduced to fix the issue reported in bug #44501.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60232
--
Edit this bug report at https://bugs.php.net/bug.php?id=60232&edit=1
Bug #61014 [Opn]: Memory leak on unserialize for certain nested objects
Edit report at https://bugs.php.net/bug.php?id=61014&edit=1 ID: 61014 User updated by:npm at nuestrared dot com Reported by:npm at nuestrared dot com Summary:Memory leak on unserialize for certain nested objects Status: Open Type: Bug Package:Performance problem Operating System: Debian Linux PHP Version:5.4SVN-2012-02-08 (snap) Block user comment: N Private report: N New Comment: Hi, if you got consistent memory usage, it is probable that your saved string cannot be unserialized correctly, try printing it or turn on PHP errors to see if the unserialize was correct. Previous Comments: [2012-02-08 19:02:59] carloschilazo at gmail dot com I'm not sure the problem is on the unserialize function; I saved the value of $str (after gzuncompress/base64_decode) (so I got the original serialized string, and hardcoded it on the script) Then ran the script and got consistent memory usage... [2012-02-08 16:24:02] npm at nuestrared dot com Description: Unserializing certain objects on a loop, incurs in increased memory consumption even when the garbage collector is enables and gc_collect_cycles() is called after each iteration. For the test script there is an increase of almost 5MB, after 100 runs, it doesn't happen with every object, but it does with the one on the test. The increase is not with every iteration but every couple of iterations, until it reaches a maximum, in this case the 4980736 bytes. This report is related to bug #60937, I had no reply on my comments. Thanks, Test script: --- The test script can be found at: http://dl.dropbox.com/u/7170408/unserialize_memleak.php Expected result: Consistent memory usage. Actual result: -- The output of the script: Iteration 0 Start Mem 786432 Cicle Mem 3145728 Diff 2359296 Iteration 1 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 2 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 3 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 4 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 5 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 6 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 7 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 8 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 9 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 10 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 11 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 12 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 13 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 14 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 15 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 16 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 17 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 18 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 19 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 20 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 21 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 22 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 23 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 24 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 25 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 26 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 27 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 28 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 29 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 30 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 31 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 32 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 33 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 34 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 35 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 36 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 37 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 38 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 39 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 40 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 41 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 42 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 43 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 44 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 45 Start Mem 786432 Cicle
Bug #29992 [Com]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992&edit=1
ID: 29992
Comment by: robbie at shapehq dot co dot uk
Reported by:fletch at pobox dot com
Summary:foreach by reference corrupts the array
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
I feel very strongly that this behavior is wrong. It's not consistent with
other languages and will cause great confusion!
Previous Comments:
[2011-10-20 04:56:50] bruce at kaskubar dot com
With all due respect to those who spend their time developing, debugging, and
explaining PHP, BALDERDASH!
Elsewhere, those of us who continue to claim "bug" are supposed to be chastened
by all the explanations that have been provided over the years. The fact that
the reports persist and the explanations grow is evidence contrary to the
finding of Bogus and in support of what is expected behavior.
Fletch's example, for example, is real and reproducible through at least v5.3.2.
How in the world can it be expected for a (second) loop and its object to
perform as though no related instructions were executed previously, and then
for that interaction to raise its ugly head for only the last iteration? It
cannot be. It can be explained. But so can an earthquake be. That doesn't make
it expected.
I am unaware of any other case where prior use of a variable affects subsequent
use of the same-named variable where its value is being explicitly reset or, as
in the case of foreach, implicitly reset by virtue of its purpose. (That is, we
can use $i as a loop counter here and as a file handle there and as long as we
don't cross their purposes in the space-time continuum, all is well.)
The only bogus thing about this bug report and all its cousins is their shared
status.
[2011-09-02 15:13:42] publcishady at gmail dot com
If you describe how it works that's not an excuse for unexpected results. I
understand why the last element becomes a reference, but I don't understand why
it SHOULD become a reference. That's obviously a bug for me.
[2011-07-18 05:03:24] martijn at twotribes dot com
Well, it is expected by the people who designed the language perhaps, but not
by me. Iterating through an array, without doing anything, shouldn't change the
array. Period. If I do something similar in another language like C++, this
will never be the result.
[2011-07-15 11:57:04] johan...@php.net
daniel,
unsetting it before might also cause a wrong result. Simple example:
This is simplified and probably no good architecture but such designs might
make sense in some situations and breaking that adds a larger inconsistency
than the current "surprising but consistent" behavior.
martijn,
Of course there is a reference at the end, absolutely expected and consistent
with the language.
[2011-07-13 06:48:49] martijn at twotribes dot com
To elaborate of why I strongly feel this is a bug and not a 'feature':
$a = array('a', 'b', 'c', 'd');
foreach ($a as &$v) { }
var_dump($a);
One would expect that every element of $a is a string. Well it was, up until I
did that foreach-with-reference. That changed the last element into string
reference:
array(4) {
[0]=>
string(1) "a"
[1]=>
string(1) "b"
[2]=>
string(1) "c"
[3]=>
&string(1) "d"
}
The PHP guys can claim that this is correct behavior all they want, but it is
fundamentally wrong from a design perspective that an array changes, without
doing anything to its elements.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=29992
--
Edit this bug report at https://bugs.php.net/bug.php?id=29992&edit=1
Bug #46130 [Com]: SOAP-ERROR: Parsing WSDL
Edit report at https://bugs.php.net/bug.php?id=46130&edit=1 ID: 46130 Comment by: rw at lightwerk dot com Reported by:cfelce at gmail dot com Summary:SOAP-ERROR: Parsing WSDL Status: No Feedback Type: Bug Package:SOAP related Operating System: GNU/Linux Ubuntu fesity PHP Version:5.2CVS-2008-09-19 (CVS) Block user comment: N Private report: N New Comment: Changing the tag to works, but we have to edit every wsdl file manually. This is not feasibly in complex environments. Previous Comments: [2010-02-23 14:45:05] sebasg37 at gmail dot com Itis not neccesary to change the service for the standard one.. simply change this tag to this one Best Regards Sebastián [2009-09-17 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-09-09 18:33:47] sjo...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2009-06-24 11:22:52] sjoerd-php at linuxonly dot nl Thank you for your bug report. The message "Unknown required WSDL extension" means that the WSDL uses some extension and specifies that the client MUST understand it in order to use the service. Appearantly, PHP SoapClient does not understand the extension, thus causing this error. Please provide the WSDL or information about the required extension. [2009-03-11 19:35:13] michael dot schramm at gmail dot com Same thing happens with PHP version 5.2.6: SOAP-ERROR: Parsing WSDL: Unknown required WSDL extension 'http://schemas.xmlsoap.org/ws/2004/09/policy' Changing the Service is not always an option! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=46130 -- Edit this bug report at https://bugs.php.net/bug.php?id=46130&edit=1
Bug #60976 [Com]: PHP crashes sometimes while parsing
Edit report at https://bugs.php.net/bug.php?id=60976&edit=1 ID: 60976 Comment by: hanssen at aeteurope dot nl Reported by:xrstf-misc at yahoo dot com Summary:PHP crashes sometimes while parsing Status: Open Type: Bug Package:Reproducible crash Operating System: Win7x64 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I experience an issue which I think is caused by the same bug (PHP crashes in line 3182 of Zend/zend_language_scanner.c (contains "if ((yych = *YYCURSOR) == '\n') goto yy203;", part of function lex_scan()). In my case I call php_strip_whitespace() on a PHP file with a length of exactly 4096 bytes (the same length as the problem file reported by the original author of this bug) and where the file ends with "?>" without trailing newline. Inspection of lines 3181 and 3182 of Zend/zend_language_scanner.c reveals YYCURSOR being advanced one byte and a '\n' being expected, which fails here because it attempts to read memory beyond allocated memory. Previous Comments: [2012-02-06 17:23:08] giunta dot gaetano at gmail dot com I also have php crashes - win7 64, apache 2.2.21 from apache lounge. No error messages left in either php or apache logs - just a "server reset connection" error from the browser. The code ran fine up to php 5.3.8 (did not test with 539). It involves executing a custom page within eZPublish, it is hard for me to trace it to a single php file / command and attach it here... [2012-02-05 15:19:32] xrstf-misc at yahoo dot com Here is the original file, wrapped in an 7z archive: http://www.xrstf.de/bug60976.7z (1KB) [2012-02-04 07:39:19] paj...@php.net Ah you already did. Which EOL do you use on your original script? Unix or windows ones? Maybe zip it and post a link to the zip file, so the contents won't be altered (lexer bug). [2012-02-04 07:37:39] paj...@php.net Please provide us the full script you use to reprodruce the crash. [2012-02-04 01:20:16] xrstf-misc at yahoo dot com Well this is the source file that caused the parse error: http://pastie.org/pastes/3312735/text (md5sum is 1bd8de828db862a5f118be4cc9773999, there are not trailing spaces and there is a blank line at the end of the file). I cannot give any shorter example. Sorry. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60976 -- Edit this bug report at https://bugs.php.net/bug.php?id=60976&edit=1
Bug #50547 [Com]: SoapServer Fatal errror in WSDL mode
Edit report at https://bugs.php.net/bug.php?id=50547&edit=1 ID: 50547 Comment by: dp0 at yandex dot ru Reported by:rsumibcay at reddoor dot biz Summary:SoapServer Fatal errror in WSDL mode Status: Open Type: Bug Package:SOAP related Operating System: Ubuntu Linux PHP Version:5.2.12 Block user comment: N Private report: N New Comment: Encoding: Violation of encoding rules was my problem too, when trying to work with WSDL created in JAVA. The problem was solved by moving to using the 1.2 version of SOAP on server and client. Previous Comments: [2011-08-17 14:28:34] chinigo at gmail dot com mdekrijger's suggestion about disabling Xdebug worked for me too. Adding xdebug_disable() immediately before the SOAP call resulted in a Fatal SOAP error being converted to a catchable SOAP fault. [2011-02-24 16:00:36] mdekrijger at e-sites dot nl Xdebug might be the problem. When using xdebug_disable() before calling the handle() method, the server responds with a proper SOAP message which says that something went wrong. [2011-02-24 09:54:31] mdekrijger at e-sites dot nl Does anyone have an alternative solution for this problem? (while this bug remains open?) We really want to provide some information about the wrong type in the return soap response. So implementing our SOAP services would be a much easier job. [2010-02-01 09:48:05] jitka at darbujanova dot cz I can confirm this. (http://bugs.php.net/bug.php?id=50895) [2009-12-21 20:18:01] rsumibcay at reddoor dot biz Description: SoapServer dies with fatal error in WSDL mode when a soap argument is a ComplexType with a member defined as int in the XSD, but the member value is passed as a non-numeric string. Reproduce code: --- 1. Define a ComplexType with an int data member: http://crkt190.reddoor.biz/fatalerror/complex_types.xsd 2. Define a WSDL that uses the ComplexType as an argument to the soap function: http://crkt190.reddoor.biz/fatalerror/fatalerror.wsdl 3. Create a soap envelope with a non-numeric string as the value for the int data member: http://crkt190.reddoor.biz/fatalerror/fatalerror-soap-envelope.xml 4. Make a soap request using the soap envelope in step 3. Expected result: The SoapServer should not die with a fatal error. The SoapServer should respond with a SoapFault, or let the call pass through so the business logic (mapped handler) can do validation and handle the error appropriately. Actual result: -- 500 HTTP response from server. The HTTP response body contains an error message and stack trace. Fatal error: SOAP-ERROR: Encoding Violation of encoding rules in ... -- Edit this bug report at https://bugs.php.net/bug.php?id=50547&edit=1
Bug #60909 [Opn]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1 ID: 60909 Updated by: jpa...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: Ok I can reproduce. Try replacing your require (which generates E_COMPILE_ERROR) by an unknown function call (which generates E_ERROR), and all's just fine So there is a trick in the error engine, any kind of fatal shouldn't be handled by user defined error handlers, here we got proof it's not the case Tip: Reproduced on 5.3.10 as well Previous Comments: [2012-01-27 18:07:20] tyr...@php.net Description: first of all sorry for the weird Summary, I couldn't come up with a better one. it is weird. so it seems that if you have a shutdown function callback set and a custom error handler which would throw and exception and you happen to have a fatal error, the shutdown function won't be called. See the attached script, the error handler shouldn't really do anything here, because it won't be called for the fatals, but somehow it still screw things up. If I remove the error handler, I will see the "!!!shutdown!!!" printed. If I put a "return false;" before the throw I will see the "!!!shutdown!!!" printed. If I add E_NOTICE as the $error_type to the set_error_handler call I will see the "!!!shutdown!!!" printed. If I add E_WARNING as the $error_type to the set_error_handler call I will NOT see the "!!!shutdown!!!" printed. wtf? Test script: --- https://bugs.php.net/bug.php?id=60909&edit=1
[PHP-BUG] Bug #61028 [NEW]: DateTime constructor ignores Timezone info in DATE_ISO8601 formated strings
From:
Operating system: OpenSuse 12.1
PHP version: 5.3.10
Package: Date/time related
Bug Type: Bug
Bug description:DateTime constructor ignores Timezone info in DATE_ISO8601
formated strings
Description:
DateTime ignores Timezone:
php -r '$d=new DateTime("2012-02-09T15:30:14+0100"); echo
$d->format(DATE_ISO8601)."\n"; $d=new DateTime("2012-02-09T14:30:14+");
echo $d->format(DATE_ISO8601)."\n";'
Output:
2012-02-09T15:30:14+0100
2012-02-09T14:30:14+
strtotime works as expected:
php -r 'echo date(DATE_ISO8601,
strtotime("2012-02-09T15:30:14+0100"))."\n"; echo date(DATE_ISO8601,
strtotime("2012-02-09T14:30:14+"))."\n";'
Output:
2012-02-09T15:30:14+0100
2012-02-09T15:30:14+0100
Test script:
---
php -r '$d=new DateTime("2012-02-09T15:30:14+0100"); echo
$d->format(DATE_ISO8601)."\n"; $d=new DateTime("2012-02-09T14:30:14+");
echo $d->format(DATE_ISO8601)."\n";'
Expected result:
2012-02-09T15:30:14+0100
2012-02-09T15:30:14+0100
Actual result:
--
2012-02-09T15:30:14+0100
2012-02-09T14:30:14+
--
Edit bug report at https://bugs.php.net/bug.php?id=61028&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61028&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61028&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61028&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61028&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61028&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61028&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61028&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61028&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61028&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61028&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61028&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61028&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61028&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61028&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61028&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61028&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61028&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61028&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61028&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61028&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61028&r=mysqlcfg
Bug #61028 [Opn->Nab]: DateTime constructor ignores Timezone info in DATE_ISO8601 formated strings
Edit report at https://bugs.php.net/bug.php?id=61028&edit=1
ID: 61028
Updated by: der...@php.net
Reported by:tom dot anheyer at berlinonline dot de
Summary:DateTime constructor ignores Timezone info in
DATE_ISO8601 formated strings
-Status: Open
+Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: OpenSuse 12.1
PHP Version:5.3.10
Block user comment: N
Private report: N
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
DateTime objects actually keep their timezone information, whereas strtotime()
removes it (as a timestamp doesn't contain tz info).
Previous Comments:
[2012-02-09 15:04:22] tom dot anheyer at berlinonline dot de
Description:
DateTime ignores Timezone:
php -r '$d=new DateTime("2012-02-09T15:30:14+0100"); echo
$d->format(DATE_ISO8601)."\n"; $d=new DateTime("2012-02-09T14:30:14+");
echo $d->format(DATE_ISO8601)."\n";'
Output:
2012-02-09T15:30:14+0100
2012-02-09T14:30:14+
strtotime works as expected:
php -r 'echo date(DATE_ISO8601, strtotime("2012-02-09T15:30:14+0100"))."\n";
echo date(DATE_ISO8601, strtotime("2012-02-09T14:30:14+"))."\n";'
Output:
2012-02-09T15:30:14+0100
2012-02-09T15:30:14+0100
Test script:
---
php -r '$d=new DateTime("2012-02-09T15:30:14+0100"); echo
$d->format(DATE_ISO8601)."\n"; $d=new DateTime("2012-02-09T14:30:14+");
echo $d->format(DATE_ISO8601)."\n";'
Expected result:
2012-02-09T15:30:14+0100
2012-02-09T15:30:14+0100
Actual result:
--
2012-02-09T15:30:14+0100
2012-02-09T14:30:14+
--
Edit this bug report at https://bugs.php.net/bug.php?id=61028&edit=1
[PHP-BUG] Bug #61029 [NEW]: '@' operator before a function call causes php to hang till max-exec-time
From: Operating system: MacOS 10.6 PHP version: 5.4.0RC7 Package: *General Issues Bug Type: Bug Bug description:'@' operator before a function call causes php to hang till max-exec-time Description: Steps to reproduce: Php 5.4RC7 on MACOS 10.6 Execute script in test script doesn't matter if index.html is actually there Note php error logs Test script: --- https://bugs.php.net/bug.php?id=61029&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61029&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61029&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61029&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61029&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61029&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61029&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61029&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61029&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61029&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61029&r=support Expected behavior: https://bugs.php.net/fix.php?id=61029&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61029&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61029&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61029&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61029&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61029&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61029&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61029&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61029&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61029&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61029&r=mysqlcfg
Bug #61029 [Opn->Fbk]: '@' operator before a function call causes php to hang till max-exec-time
Edit report at https://bugs.php.net/bug.php?id=61029&edit=1 ID: 61029 Updated by: larue...@php.net Reported by:yonni dot m at zend dot com Summary:'@' operator before a function call causes php to hang till max-exec-time -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: MacOS 10.6 PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: I can not reproduce this, could you help us to find more infos? like: run the test script. when it hanged, put the php process background (ctrl+z, then $bg). find the process's pid. gdb --pid=php's pid then gdb>bt paste the backtrace to here. thanks Previous Comments: [2012-02-09 15:36:02] yonni dot m at zend dot com Description: Steps to reproduce: Php 5.4RC7 on MACOS 10.6 Execute script in test script doesn't matter if index.html is actually there Note php error logs Test script: --- https://bugs.php.net/bug.php?id=61029&edit=1
[PHP-BUG] Bug #61030 [NEW]: Memory leak when using ssl_verifPeer true
From:
Operating system: fedora 14
PHP version: 5.3.10
Package: cURL related
Bug Type: Bug
Bug description:Memory leak when using ssl_verifPeer true
Description:
PHP 5.3.10 (cli) (built: Feb 4 2012 08:56:48)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.1.3, Copyright (c) 2002-2012, by Derick Rethans
libcurl-7.24.0-1.0.cf.fc14.i686
nss-3.12.10-7.fc14.i686
openssl-1.0.0e-1.fc14.i686
Test script:
---
#! /usr/bin/env php
https://sqs.us-east-1.amazonaws.com');
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, $memLeak);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_exec($curl);
curl_close($curl);
}
}
gc_enable();
$myPid = getmypid();$i=0;
$test = new httpsTest();
while ($test){
$test->curlHttps(true);
echo $i++ ." PHP Info MemUsage: ".memory_get_usage() ."Linux Info
";
system('cat /proc/' .$myPid .'/status|grep '.'"VmSize"');
sleep(1);
}
Expected result:
The memory usage for PHP and Linux VMSize should stay level over time,
which is
the case when $test->curlHttps(false); is used
Actual result:
--
The php memory usage is level but the Linux process memory usage is growing
with
132K bytes per 18 iterations.
--
Edit bug report at https://bugs.php.net/bug.php?id=61030&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61030&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61030&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61030&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61030&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61030&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61030&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61030&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61030&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61030&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61030&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61030&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61030&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61030&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61030&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61030&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61030&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61030&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61030&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61030&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61030&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61030&r=mysqlcfg
Bug #29992 [Nab]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992&edit=1
ID: 29992
Updated by: ras...@php.net
Reported by:fletch at pobox dot com
Summary:foreach by reference corrupts the array
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
No matter how you paint this, it isn't a bug. What you are really asking for is
some sort of block-level scoping. As such, it should be proposed as a feature
request, but it would be a major change in the language. The simplest way to
illustrate that is to just unroll the loops. Take this example:
$a = array(1,2);
foreach($a as &$b) { }
foreach($a as $b) { }
print_r($a);
The problem here is that people find it inconsistent that the 2nd loop changes
$a. But if we unroll the loops and write the exactly equivalent code without
the
foreach construct we get:
$a = array(1,2);
// First loop, $b is a reference to each element in $a
$b = &$a[0];
$b = &$a[1];
// Second loop, $b is assigned the value of each element in $a
$b = $a[0];
$b = $a[1];
Those two pieces of code are identical in every way. The thing that confuses
people is that $b is still a reference $a[1] going into the second loop.
Since PHP doesn't have block-level scoping, there is nothing in the language
that would permit $b to be unset between the two loops without introducing a
major inconsistency. In fact there is plenty of code that relies on this fact
which would break if we made such an arbitrary change.
I suppose what you are asking for is syntax along the lines of:
$a = array(1,2);
{
local $b = &$a[0];
$b = &$a[1];
}
{
local $b = $a[0];
$b = $a[1];
}
Where $b is locally scoped in each of those blocks and it might look like this
in a foreach case:
$a = array(1,2);
foreach($a as local &$b) { }
foreach($a as local $b) { }
Without such a scoping syntax change, something as simple as:
forach(array(1,2,3) as $b) { }
echo $b;
where the code fully expects $b to be 3 would break.
Previous Comments:
[2012-02-09 12:33:40] robbie at shapehq dot co dot uk
I feel very strongly that this behavior is wrong. It's not consistent with
other languages and will cause great confusion!
[2011-10-20 04:56:50] bruce at kaskubar dot com
With all due respect to those who spend their time developing, debugging, and
explaining PHP, BALDERDASH!
Elsewhere, those of us who continue to claim "bug" are supposed to be chastened
by all the explanations that have been provided over the years. The fact that
the reports persist and the explanations grow is evidence contrary to the
finding of Bogus and in support of what is expected behavior.
Fletch's example, for example, is real and reproducible through at least v5.3.2.
How in the world can it be expected for a (second) loop and its object to
perform as though no related instructions were executed previously, and then
for that interaction to raise its ugly head for only the last iteration? It
cannot be. It can be explained. But so can an earthquake be. That doesn't make
it expected.
I am unaware of any other case where prior use of a variable affects subsequent
use of the same-named variable where its value is being explicitly reset or, as
in the case of foreach, implicitly reset by virtue of its purpose. (That is, we
can use $i as a loop counter here and as a file handle there and as long as we
don't cross their purposes in the space-time continuum, all is well.)
The only bogus thing about this bug report and all its cousins is their shared
status.
[2011-09-02 15:13:42] publcishady at gmail dot com
If you describe how it works that's not an excuse for unexpected results. I
understand why the last element becomes a reference, but I don't understand why
it SHOULD become a reference. That's obviously a bug for me.
[2011-07-18 05:03:24] martijn at twotribes dot com
Well, it is expected by the people who designed the language perhaps, but not
by me. Iterating through an array, without doing anything, shouldn't change the
array. Period. If I do something similar in another language like C++, this
will never be the result.
[2011-07-15 11:57:04] johan...@php.net
daniel,
unsetting it before might also cause a wrong result. Simple example:
This is simplified and probably no good architecture but such designs might
make sense in some situations and breaking that adds a larger inconsistency
than the current "surprising but consistent" behavior.
martijn,
Of course there is
Bug #29992 [Com]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992&edit=1
ID: 29992
Comment by: looris at gmail dot com
Reported by:fletch at pobox dot com
Summary:foreach by reference corrupts the array
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
No one cares about the technical explanation about why this happens at a low
level. I'm quite puzzled you are still in denial about this bug.
Previous Comments:
[2012-02-09 16:49:22] ras...@php.net
No matter how you paint this, it isn't a bug. What you are really asking for is
some sort of block-level scoping. As such, it should be proposed as a feature
request, but it would be a major change in the language. The simplest way to
illustrate that is to just unroll the loops. Take this example:
$a = array(1,2);
foreach($a as &$b) { }
foreach($a as $b) { }
print_r($a);
The problem here is that people find it inconsistent that the 2nd loop changes
$a. But if we unroll the loops and write the exactly equivalent code without
the
foreach construct we get:
$a = array(1,2);
// First loop, $b is a reference to each element in $a
$b = &$a[0];
$b = &$a[1];
// Second loop, $b is assigned the value of each element in $a
$b = $a[0];
$b = $a[1];
Those two pieces of code are identical in every way. The thing that confuses
people is that $b is still a reference $a[1] going into the second loop.
Since PHP doesn't have block-level scoping, there is nothing in the language
that would permit $b to be unset between the two loops without introducing a
major inconsistency. In fact there is plenty of code that relies on this fact
which would break if we made such an arbitrary change.
I suppose what you are asking for is syntax along the lines of:
$a = array(1,2);
{
local $b = &$a[0];
$b = &$a[1];
}
{
local $b = $a[0];
$b = $a[1];
}
Where $b is locally scoped in each of those blocks and it might look like this
in a foreach case:
$a = array(1,2);
foreach($a as local &$b) { }
foreach($a as local $b) { }
Without such a scoping syntax change, something as simple as:
forach(array(1,2,3) as $b) { }
echo $b;
where the code fully expects $b to be 3 would break.
[2012-02-09 12:33:40] robbie at shapehq dot co dot uk
I feel very strongly that this behavior is wrong. It's not consistent with
other languages and will cause great confusion!
[2011-10-20 04:56:50] bruce at kaskubar dot com
With all due respect to those who spend their time developing, debugging, and
explaining PHP, BALDERDASH!
Elsewhere, those of us who continue to claim "bug" are supposed to be chastened
by all the explanations that have been provided over the years. The fact that
the reports persist and the explanations grow is evidence contrary to the
finding of Bogus and in support of what is expected behavior.
Fletch's example, for example, is real and reproducible through at least v5.3.2.
How in the world can it be expected for a (second) loop and its object to
perform as though no related instructions were executed previously, and then
for that interaction to raise its ugly head for only the last iteration? It
cannot be. It can be explained. But so can an earthquake be. That doesn't make
it expected.
I am unaware of any other case where prior use of a variable affects subsequent
use of the same-named variable where its value is being explicitly reset or, as
in the case of foreach, implicitly reset by virtue of its purpose. (That is, we
can use $i as a loop counter here and as a file handle there and as long as we
don't cross their purposes in the space-time continuum, all is well.)
The only bogus thing about this bug report and all its cousins is their shared
status.
[2011-09-02 15:13:42] publcishady at gmail dot com
If you describe how it works that's not an excuse for unexpected results. I
understand why the last element becomes a reference, but I don't understand why
it SHOULD become a reference. That's obviously a bug for me.
[2011-07-18 05:03:24] martijn at twotribes dot com
Well, it is expected by the people who designed the language perhaps, but not
by me. Iterating through an array, without doing anything, shouldn't change the
array. Period. If I do something similar in another language like C++, this
will never be the result.
The remainder of the comments for this report are too long. To view
the rest of the comments,
[PHP-BUG] Req #61031 [NEW]: Need E_COMPILE_DEPRECATED error
From: ondrej Operating system: Irrelevant PHP version: 5.3.10 Package: Output Control Bug Type: Feature/Change Request Bug description:Need E_COMPILE_DEPRECATED error Description: Hi, it's probably non-issue for 5.4, but in 5.3.x the "Call-time pass-by-reference has been deprecated" is declared as E_DEPRECATED while in fact is is evaluated at compile time and thus more correct would be E_COMPILE_DEPRECATED error. See the: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647641 O. Test script: --- Expected result: Depends on the settings of your php.ini, but prints error as E_DEPRECATED (which is marked as run-time error setting. Actual result: -- Depends on the settings of your php.ini and prints error as E_COMPILE_DEPRECATED. -- Edit bug report at https://bugs.php.net/bug.php?id=61031&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61031&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61031&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61031&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61031&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61031&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61031&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61031&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61031&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61031&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61031&r=support Expected behavior: https://bugs.php.net/fix.php?id=61031&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61031&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61031&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61031&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61031&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61031&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61031&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61031&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61031&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61031&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61031&r=mysqlcfg
Req #61017 [Fbk->Opn]: ~ in include_path
Edit report at https://bugs.php.net/bug.php?id=61017&edit=1 ID: 61017 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:~ in include_path -Status: Feedback +Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.10 Block user comment: N Private report: N New Comment: right, people are still using mod_php :( That of course is not a issue with suexec + fastcgi Previous Comments: [2012-02-08 17:25:31] ras...@php.net How would that work? Generally the web server will run as some generic user, so ~ and $LOGIN will not have a meaningful value. [2012-02-08 17:21:02] spamik at yum dot pl Description: include_path needs something for home directory or username substitution. Without it tens of tousands of unmanagable php.ini specific to every username are needed. in php.ini include_path = ".:~/pear/php/" or include_path = ".:/home/$LOGIN/pear/php/" -- Edit this bug report at https://bugs.php.net/bug.php?id=61017&edit=1
Bug #29992 [Nab]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992&edit=1
ID: 29992
Updated by: ras...@php.net
Reported by:fletch at pobox dot com
Summary:foreach by reference corrupts the array
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
What do you mean you con't care about the explanation?
Ok, simple question then. Do you expect this to output 3?
foreach(array(1,2,3) as $b) { }
echo $b;
If you do, then you don't want us to fix this "bug" because fixing it would
mean
$b is not 3 here.
Previous Comments:
[2012-02-09 16:55:31] looris at gmail dot com
No one cares about the technical explanation about why this happens at a low
level. I'm quite puzzled you are still in denial about this bug.
[2012-02-09 16:49:22] ras...@php.net
No matter how you paint this, it isn't a bug. What you are really asking for is
some sort of block-level scoping. As such, it should be proposed as a feature
request, but it would be a major change in the language. The simplest way to
illustrate that is to just unroll the loops. Take this example:
$a = array(1,2);
foreach($a as &$b) { }
foreach($a as $b) { }
print_r($a);
The problem here is that people find it inconsistent that the 2nd loop changes
$a. But if we unroll the loops and write the exactly equivalent code without
the
foreach construct we get:
$a = array(1,2);
// First loop, $b is a reference to each element in $a
$b = &$a[0];
$b = &$a[1];
// Second loop, $b is assigned the value of each element in $a
$b = $a[0];
$b = $a[1];
Those two pieces of code are identical in every way. The thing that confuses
people is that $b is still a reference $a[1] going into the second loop.
Since PHP doesn't have block-level scoping, there is nothing in the language
that would permit $b to be unset between the two loops without introducing a
major inconsistency. In fact there is plenty of code that relies on this fact
which would break if we made such an arbitrary change.
I suppose what you are asking for is syntax along the lines of:
$a = array(1,2);
{
local $b = &$a[0];
$b = &$a[1];
}
{
local $b = $a[0];
$b = $a[1];
}
Where $b is locally scoped in each of those blocks and it might look like this
in a foreach case:
$a = array(1,2);
foreach($a as local &$b) { }
foreach($a as local $b) { }
Without such a scoping syntax change, something as simple as:
forach(array(1,2,3) as $b) { }
echo $b;
where the code fully expects $b to be 3 would break.
[2012-02-09 12:33:40] robbie at shapehq dot co dot uk
I feel very strongly that this behavior is wrong. It's not consistent with
other languages and will cause great confusion!
[2011-10-20 04:56:50] bruce at kaskubar dot com
With all due respect to those who spend their time developing, debugging, and
explaining PHP, BALDERDASH!
Elsewhere, those of us who continue to claim "bug" are supposed to be chastened
by all the explanations that have been provided over the years. The fact that
the reports persist and the explanations grow is evidence contrary to the
finding of Bogus and in support of what is expected behavior.
Fletch's example, for example, is real and reproducible through at least v5.3.2.
How in the world can it be expected for a (second) loop and its object to
perform as though no related instructions were executed previously, and then
for that interaction to raise its ugly head for only the last iteration? It
cannot be. It can be explained. But so can an earthquake be. That doesn't make
it expected.
I am unaware of any other case where prior use of a variable affects subsequent
use of the same-named variable where its value is being explicitly reset or, as
in the case of foreach, implicitly reset by virtue of its purpose. (That is, we
can use $i as a loop counter here and as a file handle there and as long as we
don't cross their purposes in the space-time continuum, all is well.)
The only bogus thing about this bug report and all its cousins is their shared
status.
[2011-09-02 15:13:42] publcishady at gmail dot com
If you describe how it works that's not an excuse for unexpected results. I
understand why the last element becomes a reference, but I don't understand why
it SHOULD become a reference. That's obviously a bug for me.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bu
Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI
Edit report at https://bugs.php.net/bug.php?id=60826&edit=1 ID: 60826 Comment by: a...@php.net Reported by:clarkwise at gmail dot com Summary:raw POST data missing with chunked encoding, FastCGI Status: Open Type: Bug Package:CGI/CLI related Operating System: Windows XP PHP Version:5.3.9 Block user comment: N Private report: N New Comment: I've additionally tested the two files on nginx with PHP as FCGI. The request simply doesn't go throught to PHP and nginx gives 401 back. I've attached gdb to the PHP and set a break in the accept loop - there was no reaction when using the two test files, but requests without data got down to PHP. So my conclusion were - apache simply ignores the request body where nginx gives a correct http status. Anyways, this has nothing to do with PHP. IIS, Apache and Nginx seem to have no implementation for chunked incoming body stuff, but they do handle that a different way. Btw. Nginx has the "chunkin" module for such actions. Previous Comments: [2012-02-02 00:35:42] timo dot witte at googlemail dot com I have the same problem on my machine and can confirm this bug! i think this bug affects mod_spdy aswell, because it sends the POST data chunked! ( http://code.google.com/p/mod-spdy/issues/detail?id=22 ). [2012-01-20 21:15:54] clarkwise at gmail dot com Description: When a POST is sent with the header "Transfer-Encoding: chunked" and PHP 5.3 is running via FastCGI, $HTTP_RAW_POST_DATA is not set. In IIS, the receiving PHP process simply hangs and does not execute at all. If chunked encoding is not set, it executes successfully and $HTTP_RAW_POST_DATA is populated. Comparing ISAPI to FastCGI (using PHP 5.2 which has both implementations), PHP ISAPI works fine with "Transfer-Encoding: chunked" but PHP FastCGI does not. This issue also occurred running Linux/Apache with PHP 5.3 FastCGI. In that scenario, the PHP process did not completely hang, but $HTTP_RAW_POST_DATA and php://input were empty when the script executed. Test script: --- Two files, postsend.php and postreceive.php, can be found within the question here: http://stackoverflow.com/questions/8899239/http-raw-post-data-not-being-populated-after-upgrade-to-php-5-3 Expected result: $HTTP_RAW_POST_DATA and the php://input stream should contain the raw binary data that was sent in the POST. Actual result: -- On Windows/IIS, the PHP process hangs and does not execute. On Linux/Apache, the PHP process executes but $HTTP_RAW_POST_DATA and php://input are empty. -- Edit this bug report at https://bugs.php.net/bug.php?id=60826&edit=1
Bug #61010 [Nab]: Segfault (11) on oci_connect
Edit report at https://bugs.php.net/bug.php?id=61010&edit=1
ID: 61010
User updated by:lars at larsdebruin dot net
Reported by:lars at larsdebruin dot net
Summary:Segfault (11) on oci_connect
Status: Not a bug
Type: Bug
Package:OCI8 related
Operating System: Redhat Linux 6.2
PHP Version:5.3.10
Assigned To:sixd
Block user comment: N
Private report: N
New Comment:
1. used the new oracle client
2. nothing i can do about it :)
3. compiled into PHP, not as module
4. removed the option
Same error, i recompiled PHP without OCI.
it worked using: pecl install oci8
Previous Comments:
[2012-02-09 00:58:52] s...@php.net
Doesn't reproduce for me on Oracle Linux 6.2. I spent some time
getting as close to your configuration as possible. I saw no failures
with various scenarios including invalid passwords, invalid connection
strings and expired passwords (https://bugs.php.net/bug.php?id=58477)
$ php -r '$c = oci_connect("cj", "cj", "mymachine/abc");
var_dump($c);' resource(5) of type (oci8 connection)
Some comments:
1. Oracle Instant Client 10.1 is very old. Unless you need it for a
reason reason, use at least 11.2.
http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html
2. Oracle DB & client isn't certified on RHEL 6, so all bets about
behavior are off.
3. Why build only OCI8 shared?
4. The configure line has "--enable-mysqlnd" but none of the MySQL
extension options say to use mysqlnd, so the MySQL client libraries
are still being used.
[2012-02-08 13:31:12] lars at larsdebruin dot net
Description:
build:
./configure --with-libxml-dir --enable-bcmath --with-openssl --with-kerberos --
with-zlib --with-bz2 --with-libdir=lib64 --enable-calendar --with-curl --enable-
exif --enable-ftp --with-gd --with-ldap --with-ldap-sasl --enable-mbstring --
with-mcrypt --with-mysql --with-pdo-mysql --with-mysqli --with-
oci8=shared,instantclient,/root/oracle --enable-soap --enable-sockets --with-
gettext --enable-zip --with-mhash --with-pcre-regex --enable-shmop --enable-
sysvmsg --enable-mysqlnd --with-unixODBC --with-apxs2=/usr/sbin/apxs --disable-
cgi
PHPinfo:
OCI8 Supportenabled
Version 1.4.7
Revision$Revision: 321634 $
Active Persistent Connections 0
Active Connections 0
Oracle Instant Client Version 10.1
Temporary Lob support enabled
Collections support enabled
Test script:
---
Expected result:
<>: php oracleconnect.php
Segmentation fault (core dumped)
Core dump is NOT generated
Actual result:
--
Core dump is not generated by PHP?
--
Edit this bug report at https://bugs.php.net/bug.php?id=61010&edit=1
[PHP-BUG] Bug #61032 [NEW]: False value for blank last line with SKIP_EMPTY andDROP_NEW_LINE
From:
Operating system: Fedora 16
PHP version: 5.3.10
Package: SPL related
Bug Type: Bug
Bug description:False value for blank last line with SKIP_EMPTY
andDROP_NEW_LINE
Description:
Suddenly, using SplFileObject::SKIP_EMPTY and SplFileObject::DROP_NEW_LINE
no longer ignores a final blank line in a file. Instead, when iterating
over the file object, the last value is boolean false. This appears to have
changed between 5.3.8 and 5.3.9 and persists in 5.3.10.
Test script:
---
setFlags( SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE );
foreach ($TheFile as $line) {
print "Currently on key " . $TheFile->key() . ": " . PHP_EOL;
var_dump($line);
}
Expected result:
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Actual result:
--
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Currently on key 2:
bool(false)
--
Edit bug report at https://bugs.php.net/bug.php?id=61032&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61032&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61032&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61032&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61032&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61032&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61032&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61032&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61032&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61032&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61032&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61032&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61032&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61032&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61032&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61032&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61032&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61032&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61032&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61032&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61032&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61032&r=mysqlcfg
Bug #61032 [Opn->Ana]: False value for blank last line with SKIP_EMPTY andDROP_NEW_LINE
Edit report at https://bugs.php.net/bug.php?id=61032&edit=1
ID: 61032
Updated by: ras...@php.net
Reported by:jcampbell at remindermedia dot com
Summary:False value for blank last line with SKIP_EMPTY
andDROP_NEW_LINE
-Status: Open
+Status: Analyzed
Type: Bug
Package:SPL related
Operating System: Fedora 16
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
This was caused by fixing bug 55807
Previous Comments:
[2012-02-09 19:41:32] jcampbell at remindermedia dot com
Description:
Suddenly, using SplFileObject::SKIP_EMPTY and SplFileObject::DROP_NEW_LINE no
longer ignores a final blank line in a file. Instead, when iterating over the
file object, the last value is boolean false. This appears to have changed
between 5.3.8 and 5.3.9 and persists in 5.3.10.
Test script:
---
setFlags( SplFileObject::SKIP_EMPTY | SplFileObject::DROP_NEW_LINE );
foreach ($TheFile as $line) {
print "Currently on key " . $TheFile->key() . ": " . PHP_EOL;
var_dump($line);
}
Expected result:
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Actual result:
--
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Currently on key 2:
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61032&edit=1
[PHP-BUG] Bug #61033 [NEW]: __FUNCTION__ doesn't report correctly in alias trait methods
From: Operating system: Gentoo PHP version: 5.4.0RC7 Package: Reflection related Bug Type: Bug Bug description:__FUNCTION__ doesn't report correctly in alias trait methods Description: The __FUNCTION__ magic constant does not report correctly in aliased methods within traits. When a trait function is called by it's initial name __FUNCTION__ is correct. When it is called by it aliased name __FUNCTION__ still reports as the initial name, but debug_backtrace() reports the aliased method name. Test script: --- foo(); echo PHP_EOL; echo 'bar()' . PHP_EOL; $instance->bar(); Expected result: foo() __FUNCTION__ = foo $backtrace[0]['function']) = foo bar() __FUNCTION__ = bar $backtrace[0]['function']) = bar Actual result: -- foo() __FUNCTION__ = foo $backtrace[0]['function']) = foo bar() __FUNCTION__ = foo $backtrace[0]['function']) = bar -- Edit bug report at https://bugs.php.net/bug.php?id=61033&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61033&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61033&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61033&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61033&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61033&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61033&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61033&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61033&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61033&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61033&r=support Expected behavior: https://bugs.php.net/fix.php?id=61033&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61033&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61033&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61033&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61033&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61033&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61033&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61033&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61033&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61033&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61033&r=mysqlcfg
Req->Bug #55807 [Csd->ReO]: Wrong value for splFileObject::SKIP_EMPTY
Edit report at https://bugs.php.net/bug.php?id=55807&edit=1
ID: 55807
Updated by: ras...@php.net
Reported by:jgotti at modedemploi dot fr
Summary:Wrong value for splFileObject::SKIP_EMPTY
-Status: Closed
+Status: Re-Opened
-Type: Feature/Change Request
+Type: Bug
Package:SPL related
Operating System: linux
PHP Version:5.3.8
Assigned To:colder
Block user comment: N
Private report: N
New Comment:
This fix was not correct. SKIP_EMPTY included READ_AHEAD on purpose. See
Helly's
original commit message:
http://svn.php.net/viewvc?view=revision&revision=212726
This is now causing problems. See bug 61032
We need to either revert this, or change the logic to restore the original
behaviour of SKIP_EMPTY
Previous Comments:
[2011-09-30 14:17:33] bj...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-09-30 14:17:20] bj...@php.net
Heh. Excellent point :)
[2011-09-30 14:17:02] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=317501
Log: Fixed bug #55807 (Wrong value for splFileObject::SKIP_EMPTY)
[2011-09-28 15:21:05] jgotti at modedemploi dot fr
Description:
isn't this weird that splFileObject::SKIP_EMPTY=6.
I think this should be 4 and not 6 as setting splFileObject flag to SKIP_EMPTY
will report flag splFileObject::READ_AHEAD to be set even if not intended to be
set
Test script:
---
$fileObj = new SplFileObject('/tmp/test.txt');
$fileObj->setFlags(SplFileObject::SKIP_EMPTY);
if( $fileObj->getFlags() & SplFileObject::READ_AHEAD ){//<-- should not pass
here we didn't set READ_AHEAD flag
echo "READ_AHEAD on";
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=55807&edit=1
Bug #61033 [Opn]: __FUNCTION__ doesn't report correctly in alias trait methods
Edit report at https://bugs.php.net/bug.php?id=61033&edit=1 ID: 61033 Updated by: g...@php.net Reported by:marc at easen dot co dot uk Summary:__FUNCTION__ doesn't report correctly in alias trait methods Status: Open Type: Bug Package:Reflection related Operating System: Gentoo PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: While it made sense to change __CLASS__ to report the using class (since a trait is not a class), I do not think that it makes much sense to change __FUNCTION__ to do such magic. __FUNCTION__ referes here to the compile time name of the lexical entity the magic constant is embedded in. Thus, it is the name you'll find in the code. (since there is no lexical entity class, we can fall back to the using class without having to explain to much). (And __TRAIT__ is also not changed on usage when composing traits, it is a lexical reference). That's what comes to my mind when thinking about this question. I would suggest that you write a mail to the internals mailing list to start a discussion. This might still be a controversial thing. I will classify it as intended behavior for the moment Thanks (and please start a discussion on the mailing list if you disagree) Stefan Previous Comments: [2012-02-09 20:23:48] marc at easen dot co dot uk Description: The __FUNCTION__ magic constant does not report correctly in aliased methods within traits. When a trait function is called by it's initial name __FUNCTION__ is correct. When it is called by it aliased name __FUNCTION__ still reports as the initial name, but debug_backtrace() reports the aliased method name. Test script: --- foo(); echo PHP_EOL; echo 'bar()' . PHP_EOL; $instance->bar(); Expected result: foo() __FUNCTION__ = foo $backtrace[0]['function']) = foo bar() __FUNCTION__ = bar $backtrace[0]['function']) = bar Actual result: -- foo() __FUNCTION__ = foo $backtrace[0]['function']) = foo bar() __FUNCTION__ = foo $backtrace[0]['function']) = bar -- Edit this bug report at https://bugs.php.net/bug.php?id=61033&edit=1
Bug #61033 [Opn->Nab]: __FUNCTION__ doesn't report correctly in alias trait methods
Edit report at https://bugs.php.net/bug.php?id=61033&edit=1 ID: 61033 Updated by: g...@php.net Reported by:marc at easen dot co dot uk Summary:__FUNCTION__ doesn't report correctly in alias trait methods -Status: Open +Status: Not a bug Type: Bug Package:Reflection related Operating System: Gentoo PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: Forgot to set the status. Previous Comments: [2012-02-09 20:43:18] g...@php.net While it made sense to change __CLASS__ to report the using class (since a trait is not a class), I do not think that it makes much sense to change __FUNCTION__ to do such magic. __FUNCTION__ referes here to the compile time name of the lexical entity the magic constant is embedded in. Thus, it is the name you'll find in the code. (since there is no lexical entity class, we can fall back to the using class without having to explain to much). (And __TRAIT__ is also not changed on usage when composing traits, it is a lexical reference). That's what comes to my mind when thinking about this question. I would suggest that you write a mail to the internals mailing list to start a discussion. This might still be a controversial thing. I will classify it as intended behavior for the moment Thanks (and please start a discussion on the mailing list if you disagree) Stefan [2012-02-09 20:23:48] marc at easen dot co dot uk Description: The __FUNCTION__ magic constant does not report correctly in aliased methods within traits. When a trait function is called by it's initial name __FUNCTION__ is correct. When it is called by it aliased name __FUNCTION__ still reports as the initial name, but debug_backtrace() reports the aliased method name. Test script: --- foo(); echo PHP_EOL; echo 'bar()' . PHP_EOL; $instance->bar(); Expected result: foo() __FUNCTION__ = foo $backtrace[0]['function']) = foo bar() __FUNCTION__ = bar $backtrace[0]['function']) = bar Actual result: -- foo() __FUNCTION__ = foo $backtrace[0]['function']) = foo bar() __FUNCTION__ = foo $backtrace[0]['function']) = bar -- Edit this bug report at https://bugs.php.net/bug.php?id=61033&edit=1
Bug #61032 [Ana]: False value for blank last line with SKIP_EMPTY andDROP_NEW_LINE
Edit report at https://bugs.php.net/bug.php?id=61032&edit=1
ID: 61032
Updated by: ras...@php.net
Reported by:jcampbell at remindermedia dot com
Summary:False value for blank last line with SKIP_EMPTY
andDROP_NEW_LINE
Status: Analyzed
Type: Bug
Package:SPL related
Operating System: Fedora 16
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Until we fix this and to be compatible with the broken versions, you can simply
add SplFileObject::READ_AHEAD. This won't break anything for past nor future
versions since that is what SplFileObject::SKIP_EMPTY implied before.
Previous Comments:
[2012-02-09 20:22:05] ras...@php.net
This was caused by fixing bug 55807
[2012-02-09 19:41:32] jcampbell at remindermedia dot com
Description:
Suddenly, using SplFileObject::SKIP_EMPTY and SplFileObject::DROP_NEW_LINE no
longer ignores a final blank line in a file. Instead, when iterating over the
file object, the last value is boolean false. This appears to have changed
between 5.3.8 and 5.3.9 and persists in 5.3.10.
Test script:
---
setFlags( SplFileObject::SKIP_EMPTY | SplFileObject::DROP_NEW_LINE );
foreach ($TheFile as $line) {
print "Currently on key " . $TheFile->key() . ": " . PHP_EOL;
var_dump($line);
}
Expected result:
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Actual result:
--
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Currently on key 2:
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61032&edit=1
Bug #61032 [Com]: False value for blank last line with SKIP_EMPTY andDROP_NEW_LINE
Edit report at https://bugs.php.net/bug.php?id=61032&edit=1
ID: 61032
Comment by: jcampbell at remindermedia dot com
Reported by:jcampbell at remindermedia dot com
Summary:False value for blank last line with SKIP_EMPTY
andDROP_NEW_LINE
Status: Analyzed
Type: Bug
Package:SPL related
Operating System: Fedora 16
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Thanks. I should have realized that after reading bug 55807.
Previous Comments:
[2012-02-09 22:25:59] ras...@php.net
Until we fix this and to be compatible with the broken versions, you can simply
add SplFileObject::READ_AHEAD. This won't break anything for past nor future
versions since that is what SplFileObject::SKIP_EMPTY implied before.
[2012-02-09 20:22:05] ras...@php.net
This was caused by fixing bug 55807
[2012-02-09 19:41:32] jcampbell at remindermedia dot com
Description:
Suddenly, using SplFileObject::SKIP_EMPTY and SplFileObject::DROP_NEW_LINE no
longer ignores a final blank line in a file. Instead, when iterating over the
file object, the last value is boolean false. This appears to have changed
between 5.3.8 and 5.3.9 and persists in 5.3.10.
Test script:
---
setFlags( SplFileObject::SKIP_EMPTY | SplFileObject::DROP_NEW_LINE );
foreach ($TheFile as $line) {
print "Currently on key " . $TheFile->key() . ": " . PHP_EOL;
var_dump($line);
}
Expected result:
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Actual result:
--
Currently on key 0:
string(15) "non-blank line1"
Currently on key 1:
string(15) "non-blank line2"
Currently on key 2:
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61032&edit=1
Bug #45191 [Com]: error_log ignores date.timezone php.ini val when setting logging timestamps
Edit report at https://bugs.php.net/bug.php?id=45191&edit=1 ID: 45191 Comment by: daniel dot caillibaud at sesamath dot net Reported by:info at organicdata dot co dot za Summary:error_log ignores date.timezone php.ini val when setting logging timestamps Status: Closed Type: Bug Package:Date/time related Operating System: Centos el5 PHP Version:5.2CVS-2008-06-05 (snap) Assigned To:derick Block user comment: N Private report: N New Comment: In an openvz VM, with php-fpm 5.3.10 (debian squeeze OS), with a sytem date configured on UTC+1 (on physical host, but `date` in VM also show UTC+1), in php.ini I've a date.timezone = "Europe/Paris" but php error_log date is displayed as UTC [09-Feb-2012 23:15:08 UTC] PHP Notice: ... while all others logs are in the system timezone, e.g nginx [10/Feb/2012:00:16:46 +0100] ... and syslog as well is UTC+1 (but doesn't show it on each log line). Hope it helps... Previous Comments: [2012-01-30 09:20:08] wadkar at gmail dot com This bug may still be a problem for someone, here are the details : # php -v PHP 5.3.8 (cli) (built: Dec 1 2011 12:23:50) The problem is with the OS this time= CentOS 5+OpenVZ with IUS repo. The host machine (with the OpenVZ kernel) has no problems # uname -a Linux vz-node2 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux # echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r 'error_reporting(-1); SOMEBADCONSTANT;' && cat /tmp/error.log && date [30-Jan-2012 14:38:56] PHP Notice: Use of undefined constant SOMEBADCONSTANT - assumed 'SOMEBADCONSTANT' in Command line code on line 1 Mon Jan 30 14:38:56 IST 2012 The same code snippet, however, when run on a VM gives # uname -a Linux container1 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux # echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r 'error_reporting(-1); SOMEBADCONSTANT;' && cat /tmp/error.log && date [30-Jan-2012 09:10:05 UTC] PHP Notice: Use of undefined constant SOMEBADCONSTANT - assumed 'SOMEBADCONSTANT' in Command line code on line 1 Mon Jan 30 14:40:05 IST 2012 The internal TZ settings are respected though: # php -i | grep timezone Default timezone => Asia/Calcutta date.timezone => Asia/Calcutta => Asia/Calcutta # php -r 'echo date_default_timezone_get(), PHP_EOL; $d = new DateTime(); echo $d->format(DATE_RFC822), PHP_EOL;' && date Asia/Calcutta Mon, 30 Jan 12 14:49:17 +0530 Mon Jan 30 14:49:17 IST 2012 I am not sure if this is the bug with PHP or with virtualized environment. I just wanted to comment/report my observation. I was worried for a moment that my CLI scripts would fail to respect the TZ settings, but that is not the case. Thanks -Sudarshan Wadkar [2009-05-03 19:09:31] der...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-07-29 06:46:39] der...@php.net It should be switched from strftime() to php_format_date(). This is not an issue with the Date/Time functionality though, but with the syslog one. [2008-07-28 22:47:26] j...@php.net Derick, any comments? [2008-07-28 22:46:30] j...@php.net Actually error_log="somefile.log" does not use any syslog stuff to write the entries in it. This is the line from main.c:490 which gets executed if error_log != syslog: strftime(error_time_str, sizeof(error_time_str), "%d-%b-%Y %H:%M:%S", php_localtime_r(&error_time, &tmbuf)); There are 2 problems here: [a] it's using locale sensitive %b modifier [b] It doesn't care about date.timezone. Solutions: [a] IMO it should use this pattern instead: "%Y-%m-%d %H:%M:%S" (f.e. lighttpd uses this for it's error_log entries :) [b] I don't know how to safely achieve the above mentioned issues with date.timezone vs. system timezone. Might be better leave this as is.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=45191 -- Edit this bug report at https://bugs.php.net/bug.php?id=45191&edit=1
Bug #60976 [Opn]: PHP crashes sometimes while parsing
Edit report at https://bugs.php.net/bug.php?id=60976&edit=1 ID: 60976 User updated by:xrstf-misc at yahoo dot com Reported by:xrstf-misc at yahoo dot com Summary:PHP crashes sometimes while parsing Status: Open Type: Bug Package:Reproducible crash Operating System: Win7x64 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: This is actually a good hint by hanssen at aeteurope dot nl: I too had some cases where a generated cache file (containing "" without trailing newline. Inspection of lines 3181 and 3182 of Zend/zend_language_scanner.c reveals YYCURSOR being advanced one byte and a '\n' being expected, which fails here because it attempts to read memory beyond allocated memory. [2012-02-06 17:23:08] giunta dot gaetano at gmail dot com I also have php crashes - win7 64, apache 2.2.21 from apache lounge. No error messages left in either php or apache logs - just a "server reset connection" error from the browser. The code ran fine up to php 5.3.8 (did not test with 539). It involves executing a custom page within eZPublish, it is hard for me to trace it to a single php file / command and attach it here... [2012-02-05 15:19:32] xrstf-misc at yahoo dot com Here is the original file, wrapped in an 7z archive: http://www.xrstf.de/bug60976.7z (1KB) [2012-02-04 07:39:19] paj...@php.net Ah you already did. Which EOL do you use on your original script? Unix or windows ones? Maybe zip it and post a link to the zip file, so the contents won't be altered (lexer bug). [2012-02-04 07:37:39] paj...@php.net Please provide us the full script you use to reprodruce the crash. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60976 -- Edit this bug report at https://bugs.php.net/bug.php?id=60976&edit=1
[PHP-BUG] Bug #61035 [NEW]: Null byte truncates $_GET variables
From:
Operating system: linux (debian squeeze)
PHP version: 5.3SVN-2012-02-10 (SVN)
Package: Apache2 related
Bug Type: Bug
Bug description:Null byte truncates $_GET variables
Description:
I was working with some serialization and I found that if there's a null
byte in
the $_GET variable the variable and the string disappear.
I'm not sure why a serialized object is using a null byte for private or
protected
members in the first place, as null bytes are used for termination.
Test script:
---
on the server:
Expected result:
If we send a request:
GET /bla.php?
rest_data=O:14:"LoadsCacheFile":11{s:12:"\x00*\x00_FileName";s:5:"Cache";}
HTTP/1.0
Host: 192.168.98.134
reply: 'array (\n'
array (
'rest_data' => 'O:14:"LoadsCacheFile":11:{s:12:"',
)
--
Edit bug report at https://bugs.php.net/bug.php?id=61035&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61035&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61035&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61035&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61035&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61035&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61035&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61035&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61035&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61035&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61035&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61035&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61035&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61035&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61035&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61035&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61035&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61035&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61035&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61035&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61035&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61035&r=mysqlcfg
[PHP-BUG] Bug #61037 [NEW]: Cookie Name Changing
From: Operating system: Windows 7 Prof PHP version: 5.3SVN-2012-02-10 (SVN) Package: Apache related Bug Type: Bug Bug description:Cookie Name Changing Description: My application supports user IDs with underscore or dot between alphanumeric string. The users preferences are stored in cookies. The cookie key is prefixed with the user id. It is observed that the dots in the userIDs are getting converted to underscores in the setCookie method. The same replacement doesn't appear to happen during retrieve and hence the application fails to detect the preferences. Sample Script: Output Array ( [test_cookie_error] => something ) Test script: --- Expected result: Array ( [test.cookie.error] => something ) Actual result: -- Array ( [test_cookie_error] => something ) -- Edit bug report at https://bugs.php.net/bug.php?id=61037&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61037&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61037&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61037&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61037&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61037&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61037&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61037&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61037&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61037&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61037&r=support Expected behavior: https://bugs.php.net/fix.php?id=61037&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61037&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61037&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61037&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61037&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61037&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61037&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61037&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61037&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61037&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61037&r=mysqlcfg
