[PHP-BUG] Bug #52123 [NEW]: strtotim() returns date for one year ago
From:
Operating system: Windows
PHP version: 5.3.2
Package: *Data Exchange functions
Bug Type: Bug
Bug description:strtotim() returns date for one year ago
Description:
Hi,
strtotime returns wrong date (one year ago) with some formats like:
2011, February 8
Test script:
---
echo (date('Y-m-d', strtotime(2011, February 8)));
Expected result:
2011-02-08
Actual result:
--
2010-02-08
--
Edit bug report at http://bugs.php.net/bug.php?id=52123edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52123r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52123r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52123r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52123r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52123r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52123r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52123r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52123r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52123r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52123r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52123r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52123r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52123r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52123r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52123r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52123r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52123r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52123r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52123r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52123r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52123r=mysqlcfg
Bug #52123 [Opn-Bgs]: strtotim() returns date for one year ago
Edit report at http://bugs.php.net/bug.php?id=52123edit=1
ID: 52123
Updated by: der...@php.net
Reported by: alipendashteh at gmail dot com
Summary: strtotim() returns date for one year ago
-Status: Open
+Status: Bogus
Type: Bug
-Package: *Data Exchange functions
+Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
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
This is not a bug. 2011 is seen as time instead:
php -r 'var_dump(date_parse(2011, February 8));'
array(12) {
[year]=
bool(false)
[month]=
int(2)
[day]=
int(8)
[hour]=
int(20)
[minute]=
int(11)
[second]=
int(0)
[fraction]=
bool(false)
[warning_count]=
int(0)
[warnings]=
array(0) {
}
[error_count]=
int(0)
[errors]=
array(0) {
}
[is_localtime]=
bool(false)
}
Previous Comments:
[2010-06-19 11:22:14] alipendashteh at gmail dot com
Description:
Hi,
strtotime returns wrong date (one year ago) with some formats like:
2011, February 8
Test script:
---
echo (date('Y-m-d', strtotime(2011, February 8)));
Expected result:
2011-02-08
Actual result:
--
2010-02-08
--
Edit this bug report at http://bugs.php.net/bug.php?id=52123edit=1
[PHP-BUG] Req #52124 [NEW]: [strpos] Limit search inside $haystack by new $length parameter
From: Operating system: PHP version: Irrelevant Package: Strings related Bug Type: Feature/Change Request Bug description:[strpos] Limit search inside $haystack by new $length parameter Description: Why strpos() does not accept $length parameter with addition to $start? It would be very useful to search a $needle inside a part of $haystack sometimes. Now such behaviour can be made by combination with substr(): $string = 'The big string [with some data here] and with more data there'; // searh inside substring from offset 16 with length 19 $tmp = substr($string, 16, 19); // now real search $pos = strpos($tmp, 'data'); if (false !== $pos) $pos += 16; // original position var_dump($pos); It work, but not optimal due to redundant copy of substring. I don't need this copy, I just want to reduce searching area. Test script: --- $string = 'The big string [with some data here] and with more data there'; // search 'data' inside substring from offset 16 with length 19 $pos = strpos($string, 'data', 16, 19); var_dump($pos); Expected result: int(26) -- Edit bug report at http://bugs.php.net/bug.php?id=52124edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52124r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52124r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52124r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52124r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52124r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52124r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52124r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52124r=needscript Try newer version: http://bugs.php.net/fix.php?id=52124r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52124r=support Expected behavior: http://bugs.php.net/fix.php?id=52124r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52124r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52124r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52124r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52124r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52124r=dst IIS Stability: http://bugs.php.net/fix.php?id=52124r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52124r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52124r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52124r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52124r=mysqlcfg
Bug #52108 [Com]: PHP-Bug in Array Key
Edit report at http://bugs.php.net/bug.php?id=52108edit=1
ID: 52108
Comment by: anon at anon dot com
Reported by: goebel at arsmedia-software dot de
Summary: PHP-Bug in Array Key
Status: Open
Type: Bug
Package: JSON related
Operating System: Ubuntu 9.04 (AMD64)
PHP Version: Irrelevant
New Comment:
Hi, just passing by. I don't know why it does that but here's a more
complete test that does not require JSON:
error_reporting(-1);
//$obj = json_decode('{2:123}');
$obj = new stdClass();
$obj-{2} = 123;
var_dump($obj-{2}, $obj-{2}, $obj);
$array = (array)$obj;
var_dump($array[2], $array[2], $array);
It can access the int(123) via both 2 and 2 on the object, but even
though the array var_dump shows the 2 key to be present, and it can be
iterated, both [2] and [2] complain the offset/index is undefined.
Previous Comments:
[2010-06-17 10:19:21] goebel at arsmedia-software dot de
Description:
Hello,
I've found an error in the keys of an array. If I have a JSON-String and
decode it with json_decode and cast the returned value in an array then
I get NULL trying to access an array entry (eg array[1]). The return
value should however be a stdClass object.
Yours sincerely,
Arne Göbel
Test script:
---
$jstr = '{1: {anzahl: , preis: , einheit: ,
beschreibung: , mwst: }, 2: {anzahl: 22, preis: 3,
einheit: , beschreibung: , mwst: }, 3: {anzahl: 12,
preis: 22, einheit: , beschreibung: , mwst: }, 4:
{anzahl: , preis: , einheit: , beschreibung: , mwst:
}}';
$array = (array) json_decode($jstr);
echo 'pre';
var_dump($array[2], $array);
echo phpversion();
Expected result:
array(
2 = stdClass object
public anzahl = 22
public preis = 3
public einheit =
public beschreibung =
public mwst =
)
Actual result:
--
NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=52108edit=1
Bug #52123 [Bgs]: strtotim() returns date for one year ago
Edit report at http://bugs.php.net/bug.php?id=52123edit=1
ID: 52123
User updated by: alipendashteh at gmail dot com
Reported by: alipendashteh at gmail dot com
Summary: strtotim() returns date for one year ago
Status: Bogus
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
New Comment:
you right; this is not a bug.
but i think the Y, F j is much more common than Hi, F j.
and many application like Drupal use Y, F j as a default date format.
so parsing date as Hi, F j rather than Y, F j would cause confiusing
errors in applications.
I suggest replace the priorities of two format mentioned.
Previous Comments:
[2010-06-19 11:41:47] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is not a bug. 2011 is seen as time instead:
php -r 'var_dump(date_parse(2011, February 8));'
array(12) {
[year]=
bool(false)
[month]=
int(2)
[day]=
int(8)
[hour]=
int(20)
[minute]=
int(11)
[second]=
int(0)
[fraction]=
bool(false)
[warning_count]=
int(0)
[warnings]=
array(0) {
}
[error_count]=
int(0)
[errors]=
array(0) {
}
[is_localtime]=
bool(false)
}
[2010-06-19 11:22:14] alipendashteh at gmail dot com
Description:
Hi,
strtotime returns wrong date (one year ago) with some formats like:
2011, February 8
Test script:
---
echo (date('Y-m-d', strtotime(2011, February 8)));
Expected result:
2011-02-08
Actual result:
--
2010-02-08
--
Edit this bug report at http://bugs.php.net/bug.php?id=52123edit=1
Bug #52123 [Bgs]: strtotim() returns date for one year ago
Edit report at http://bugs.php.net/bug.php?id=52123edit=1
ID: 52123
Updated by: degeb...@php.net
Reported by: alipendashteh at gmail dot com
Summary: strtotim() returns date for one year ago
Status: Bogus
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
New Comment:
You already have DateTime::createFromFormat() if you wish to parse other
formats.
Previous Comments:
[2010-06-19 12:59:36] alipendashteh at gmail dot com
you right; this is not a bug.
but i think the Y, F j is much more common than Hi, F j.
and many application like Drupal use Y, F j as a default date format.
so parsing date as Hi, F j rather than Y, F j would cause confiusing
errors in applications.
I suggest replace the priorities of two format mentioned.
[2010-06-19 11:41:47] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is not a bug. 2011 is seen as time instead:
php -r 'var_dump(date_parse(2011, February 8));'
array(12) {
[year]=
bool(false)
[month]=
int(2)
[day]=
int(8)
[hour]=
int(20)
[minute]=
int(11)
[second]=
int(0)
[fraction]=
bool(false)
[warning_count]=
int(0)
[warnings]=
array(0) {
}
[error_count]=
int(0)
[errors]=
array(0) {
}
[is_localtime]=
bool(false)
}
[2010-06-19 11:22:14] alipendashteh at gmail dot com
Description:
Hi,
strtotime returns wrong date (one year ago) with some formats like:
2011, February 8
Test script:
---
echo (date('Y-m-d', strtotime(2011, February 8)));
Expected result:
2011-02-08
Actual result:
--
2010-02-08
--
Edit this bug report at http://bugs.php.net/bug.php?id=52123edit=1
Bug #52123 [Bgs]: strtotim() returns date for one year ago
Edit report at http://bugs.php.net/bug.php?id=52123edit=1
ID: 52123
User updated by: alipendashteh at gmail dot com
Reported by: alipendashteh at gmail dot com
Summary: strtotim() returns date for one year ago
Status: Bogus
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
New Comment:
Yes; but I meant the default behavior of strtotime() is not appropriate
now.
and i think it is absolutely better that something like 2011, February
8 parses as Y, F j instead of Hi, F j.
Previous Comments:
[2010-06-19 13:03:52] degeb...@php.net
You already have DateTime::createFromFormat() if you wish to parse other
formats.
[2010-06-19 12:59:36] alipendashteh at gmail dot com
you right; this is not a bug.
but i think the Y, F j is much more common than Hi, F j.
and many application like Drupal use Y, F j as a default date format.
so parsing date as Hi, F j rather than Y, F j would cause confiusing
errors in applications.
I suggest replace the priorities of two format mentioned.
[2010-06-19 11:41:47] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is not a bug. 2011 is seen as time instead:
php -r 'var_dump(date_parse(2011, February 8));'
array(12) {
[year]=
bool(false)
[month]=
int(2)
[day]=
int(8)
[hour]=
int(20)
[minute]=
int(11)
[second]=
int(0)
[fraction]=
bool(false)
[warning_count]=
int(0)
[warnings]=
array(0) {
}
[error_count]=
int(0)
[errors]=
array(0) {
}
[is_localtime]=
bool(false)
}
[2010-06-19 11:22:14] alipendashteh at gmail dot com
Description:
Hi,
strtotime returns wrong date (one year ago) with some formats like:
2011, February 8
Test script:
---
echo (date('Y-m-d', strtotime(2011, February 8)));
Expected result:
2011-02-08
Actual result:
--
2010-02-08
--
Edit this bug report at http://bugs.php.net/bug.php?id=52123edit=1
Bug #52077 [Com]: SNMP GET/WALK may hangs FOREVER
Edit report at http://bugs.php.net/bug.php?id=52077edit=1 ID: 52077 Comment by: larryjadams at comcast dot net Reported by: wajim at mail dot ru Summary: SNMP GET/WALK may hangs FOREVER Status: Open Type: Bug Package: SNMP related Operating System: Win XP SP3 PHP Version: 5.2.13 New Comment: Stupid WINSock does not support send and receive timeout socket options. It's a poorly implemented socket api. The net-snmp guys will have to implement with an alarm. It can not be solved here. But nice catch. Previous Comments: [2010-06-13 21:41:34] wajim at mail dot ru Description: Under a heavy GET/WALK-ing (form localhost to localhost) php may hangs forever - apache's threads becomes zombies with CLOSE_WAIT sates even all timeouts (php and apache) are elapsed many times. Call-stack of a one zombie-thread: ntoskrnl.exe!KiUnlockDispatcherDatabase+0x77 ntoskrnl.exe!KeSetEvent+0x74 ntoskrnl.exe!PspGetSetContextSpecialApc+0x4e ntoskrnl.exe!KiDeliverApc+0xb3 ntoskrnl.exe!KiSwapThread+0x64 ntoskrnl.exe!KeWaitForSingleObject+0x1c2 ntoskrnl.exe!NtWaitForSingleObject+0x9a ntoskrnl.exe!KiFastCallEntry+0xf8 ntdll.dll!KiFastSystemCallRet ntdll.dll!ZwWaitForSingleObject+0xc mswsock.dll!SockWaitForSingleObject+0x1a0 mswsock.dll!WSPRecvFrom+0x1f0 WS2_32.dll!recvfrom+0x89 php_snmp.dll!snmp_sess_read+0x21f php_snmp.dll!snmp_sess_read+0x10 php_snmp.dll!snmp_read+0x17 php_snmp.dll!snmp_synch_response_cb+0xe8 php_snmp.dll!snmp_synch_response+0x19 php_snmp.dll!php_snmp_internal+0x267 php_snmp.dll!php_snmp+0x6da php_snmp.dll!zif_snmp2_get+0x27 php5ts.dll!zend_do_fcall_common_helper_SPEC+0x7ab php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER+0xe5 php5ts.dll!execute+0x1c5 php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15 php5ts.dll!execute+0x1c5 php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15 php5ts.dll!execute+0x1c5 php5ts.dll!zend_execute_scripts+0x107 php5ts.dll!php_execute_script+0x21d php5apache.dll!apache_php_module_main+0x91 php5apache.dll!send_php+0x265 php5apache.dll!send_parsed_php+0x10 ApacheCore.dll!ap_invoke_handler+0x87 ApacheCore.dll!ap_process_request+0x2b4 ApacheCore.dll!ap_process_request+0x26 ApacheCore.dll!ap_start_restart+0x37f WS2_32.dll!WSASocketW+0x119 IMHO bad call WS2_32.dll!recvfrom in buggy ucd-snmp library may hangs. There are no socket option like setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, ... before recvfrom call. -- Edit this bug report at http://bugs.php.net/bug.php?id=52077edit=1
Bug #52077 [Com]: SNMP GET/WALK may hangs FOREVER
Edit report at http://bugs.php.net/bug.php?id=52077edit=1
ID: 52077
Comment by: wajim at mail dot ru
Reported by: wajim at mail dot ru
Summary: SNMP GET/WALK may hangs FOREVER
Status: Open
Type: Bug
Package: SNMP related
Operating System: Win XP SP3
PHP Version: 5.2.13
New Comment:
static int _sess_read(void *sessp, fd_set *fdset){
[cut]
unsigned long unblock; //WAJIM
[cut]
unblock = 1; ioctlsocket(isp-sd, FIONBIO, unblock); //WAJIM
length = recvfrom(isp-sd, (char *)packet, PACKET_LENGTH, 0, (struct
sockaddr *)from, fromlength);
unblock = 0; ioctlsocket(isp-sd, FIONBIO, unblock); //WAJIM
[cut]
}
Those my 3 lines in snmp_api.c (ucd-snmp-4.2.7.1) fixes threads hanging.
:-)
Previous Comments:
[2010-06-19 15:03:22] larryjadams at comcast dot net
Stupid WINSock does not support send and receive timeout socket options.
It's a poorly implemented socket api. The net-snmp guys will have to
implement with an alarm. It can not be solved here. But nice catch.
[2010-06-13 21:41:34] wajim at mail dot ru
Description:
Under a heavy GET/WALK-ing (form localhost to localhost) php may hangs
forever - apache's threads becomes zombies with CLOSE_WAIT sates even
all timeouts (php and apache) are elapsed many times.
Call-stack of a one zombie-thread:
ntoskrnl.exe!KiUnlockDispatcherDatabase+0x77
ntoskrnl.exe!KeSetEvent+0x74
ntoskrnl.exe!PspGetSetContextSpecialApc+0x4e
ntoskrnl.exe!KiDeliverApc+0xb3
ntoskrnl.exe!KiSwapThread+0x64
ntoskrnl.exe!KeWaitForSingleObject+0x1c2
ntoskrnl.exe!NtWaitForSingleObject+0x9a
ntoskrnl.exe!KiFastCallEntry+0xf8
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwWaitForSingleObject+0xc
mswsock.dll!SockWaitForSingleObject+0x1a0
mswsock.dll!WSPRecvFrom+0x1f0
WS2_32.dll!recvfrom+0x89
php_snmp.dll!snmp_sess_read+0x21f
php_snmp.dll!snmp_sess_read+0x10
php_snmp.dll!snmp_read+0x17
php_snmp.dll!snmp_synch_response_cb+0xe8
php_snmp.dll!snmp_synch_response+0x19
php_snmp.dll!php_snmp_internal+0x267
php_snmp.dll!php_snmp+0x6da
php_snmp.dll!zif_snmp2_get+0x27
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x7ab
php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER+0xe5
php5ts.dll!execute+0x1c5
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15
php5ts.dll!execute+0x1c5
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15
php5ts.dll!execute+0x1c5
php5ts.dll!zend_execute_scripts+0x107
php5ts.dll!php_execute_script+0x21d
php5apache.dll!apache_php_module_main+0x91
php5apache.dll!send_php+0x265
php5apache.dll!send_parsed_php+0x10
ApacheCore.dll!ap_invoke_handler+0x87
ApacheCore.dll!ap_process_request+0x2b4
ApacheCore.dll!ap_process_request+0x26
ApacheCore.dll!ap_start_restart+0x37f
WS2_32.dll!WSASocketW+0x119
IMHO bad call WS2_32.dll!recvfrom in buggy ucd-snmp library may hangs.
There are no socket option like setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO,
... before recvfrom call.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52077edit=1
Bug #52077 [Opn-Fbk]: SNMP GET/WALK may hangs FOREVER
Edit report at http://bugs.php.net/bug.php?id=52077edit=1
ID: 52077
Updated by: paj...@php.net
Reported by: wajim at mail dot ru
Summary: SNMP GET/WALK may hangs FOREVER
-Status: Open
+Status: Feedback
Type: Bug
Package: SNMP related
Operating System: Win XP SP3
PHP Version: 5.2.13
New Comment:
did you send a patch to the ucd-snmp maintainers?
If your patch is accepted I can then patch our builds, and it will be
fixed for the next 5.3.x release (can't and won't touch snmp in 5.2
touch).
Previous Comments:
[2010-06-19 15:13:44] wajim at mail dot ru
static int _sess_read(void *sessp, fd_set *fdset){
[cut]
unsigned long unblock; //WAJIM
[cut]
unblock = 1; ioctlsocket(isp-sd, FIONBIO, unblock); //WAJIM
length = recvfrom(isp-sd, (char *)packet, PACKET_LENGTH, 0, (struct
sockaddr *)from, fromlength);
unblock = 0; ioctlsocket(isp-sd, FIONBIO, unblock); //WAJIM
[cut]
}
Those my 3 lines in snmp_api.c (ucd-snmp-4.2.7.1) fixes threads hanging.
:-)
[2010-06-19 15:03:22] larryjadams at comcast dot net
Stupid WINSock does not support send and receive timeout socket options.
It's a poorly implemented socket api. The net-snmp guys will have to
implement with an alarm. It can not be solved here. But nice catch.
[2010-06-13 21:41:34] wajim at mail dot ru
Description:
Under a heavy GET/WALK-ing (form localhost to localhost) php may hangs
forever - apache's threads becomes zombies with CLOSE_WAIT sates even
all timeouts (php and apache) are elapsed many times.
Call-stack of a one zombie-thread:
ntoskrnl.exe!KiUnlockDispatcherDatabase+0x77
ntoskrnl.exe!KeSetEvent+0x74
ntoskrnl.exe!PspGetSetContextSpecialApc+0x4e
ntoskrnl.exe!KiDeliverApc+0xb3
ntoskrnl.exe!KiSwapThread+0x64
ntoskrnl.exe!KeWaitForSingleObject+0x1c2
ntoskrnl.exe!NtWaitForSingleObject+0x9a
ntoskrnl.exe!KiFastCallEntry+0xf8
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwWaitForSingleObject+0xc
mswsock.dll!SockWaitForSingleObject+0x1a0
mswsock.dll!WSPRecvFrom+0x1f0
WS2_32.dll!recvfrom+0x89
php_snmp.dll!snmp_sess_read+0x21f
php_snmp.dll!snmp_sess_read+0x10
php_snmp.dll!snmp_read+0x17
php_snmp.dll!snmp_synch_response_cb+0xe8
php_snmp.dll!snmp_synch_response+0x19
php_snmp.dll!php_snmp_internal+0x267
php_snmp.dll!php_snmp+0x6da
php_snmp.dll!zif_snmp2_get+0x27
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x7ab
php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER+0xe5
php5ts.dll!execute+0x1c5
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15
php5ts.dll!execute+0x1c5
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15
php5ts.dll!execute+0x1c5
php5ts.dll!zend_execute_scripts+0x107
php5ts.dll!php_execute_script+0x21d
php5apache.dll!apache_php_module_main+0x91
php5apache.dll!send_php+0x265
php5apache.dll!send_parsed_php+0x10
ApacheCore.dll!ap_invoke_handler+0x87
ApacheCore.dll!ap_process_request+0x2b4
ApacheCore.dll!ap_process_request+0x26
ApacheCore.dll!ap_start_restart+0x37f
WS2_32.dll!WSASocketW+0x119
IMHO bad call WS2_32.dll!recvfrom in buggy ucd-snmp library may hangs.
There are no socket option like setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO,
... before recvfrom call.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52077edit=1
Bug #51146 [Opn]: mcrypt doesn't do OFB mode correctly
Edit report at http://bugs.php.net/bug.php?id=51146edit=1 ID: 51146 User updated by: zelnaga at gmail dot com Reported by: zelnaga at gmail dot com Summary: mcrypt doesn't do OFB mode correctly Status: Open Type: Bug Package: mcrypt related Operating System: Windows XP PHP Version: 5.3.1 New Comment: What does it even mean to do OFB at the byte-level? Per http://en.wikipedia.org/wiki/File:Ofb_encryption.png, in OFB, you encrypt the IV with the key with the chosen block cipher algorithm and then XOR that against the plaintext to get the ciphertext. How do you do that at the byte level? Do you do substrings or something? Previous Comments: [2010-06-01 12:22:07] me at haravikk dot com You're using the wrong OFB mode, you need to use MCRYPT_MODE_NOFB. MCRYPT_MODE_OFB is per-byte, while MCRYPT_MODE_NOFB is per-block and gives the result you were expecting. [2010-04-13 23:36:44] zelnaga at gmail dot com I was comparing mcrypt against openssl_encrypt() and... well, either OpenSSL is wrong or mcrypt is wrong: ?php $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; echo bin2hex(openssl_encrypt(\0\0\0\0\0\0\0\0, 'DES-OFB', '', true)) . \r\n; echo bin2hex(openssl_encrypt(\0\0\0\0\0\0\0\0, 'DES-CFB', '', true)) . \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); ? ie. mcrypt, in CTR, CBC and ECB modes equal OpenSSL in OFB and CFB modes but not mcrypt in OFB and CFB modes. In other words, OpenSSL's OFB != mcrypt's OFB and they should. [2010-02-26 16:16:56] zelnaga at gmail dot com As far as I know, the IV is also used for the first round, so I am not sure if your statement holds up. Ummm... the IV - as defined in mcrypt_generic_init - is only used in the first round. Per wikipedia, the first block against which the plaintext is XOR'd is the IV encrypted with the key. That's true in both CFB and OFB modes of operation. The difference between CFB and OFB is what subsequent blocks encrypt for the keystream. So, per that, the first block should be the same. And as for my first bug report... ?php $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo urlencode(mcrypt_generic($td, '')); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo urlencode(mcrypt_generic($td, '')); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); ? All of those should produce the same ciphertext. As it stands, only ecb, cbc and ctr produce the same ciphertext. ofb and cfb produce the same thing as each other (and, for the first block, they should, as I already mentioned), however, they're not producing the same thing as any of the other modes when, in fact, they should be. [2010-02-26 10:54:01] der...@php.net As far as I know, the IV is also used for the first round, so I am not sure if your statement holds up. [2010-02-26 03:28:05] zelnaga at gmail dot com Filing a bug report is going to be a little difficult giving that, near as I can tell, the command line version of mcrypt randomly generates IV's. My first example requires the IV's be of a known value and my
Bug #51146 [Opn]: mcrypt doesn't do OFB mode correctly
Edit report at http://bugs.php.net/bug.php?id=51146edit=1 ID: 51146 User updated by: zelnaga at gmail dot com Reported by: zelnaga at gmail dot com Summary: mcrypt doesn't do OFB mode correctly Status: Open Type: Bug Package: mcrypt related Operating System: Windows XP PHP Version: 5.3.1 New Comment: Also, there's still the matter of CFB. So NOFB is what most everything else refers to as OFB but CFB'a wrong, as well, and it has no NCFB counter part. Previous Comments: [2010-06-19 15:40:10] zelnaga at gmail dot com What does it even mean to do OFB at the byte-level? Per http://en.wikipedia.org/wiki/File:Ofb_encryption.png, in OFB, you encrypt the IV with the key with the chosen block cipher algorithm and then XOR that against the plaintext to get the ciphertext. How do you do that at the byte level? Do you do substrings or something? [2010-06-01 12:22:07] me at haravikk dot com You're using the wrong OFB mode, you need to use MCRYPT_MODE_NOFB. MCRYPT_MODE_OFB is per-byte, while MCRYPT_MODE_NOFB is per-block and gives the result you were expecting. [2010-04-13 23:36:44] zelnaga at gmail dot com I was comparing mcrypt against openssl_encrypt() and... well, either OpenSSL is wrong or mcrypt is wrong: ?php $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; echo bin2hex(openssl_encrypt(\0\0\0\0\0\0\0\0, 'DES-OFB', '', true)) . \r\n; echo bin2hex(openssl_encrypt(\0\0\0\0\0\0\0\0, 'DES-CFB', '', true)) . \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); ? ie. mcrypt, in CTR, CBC and ECB modes equal OpenSSL in OFB and CFB modes but not mcrypt in OFB and CFB modes. In other words, OpenSSL's OFB != mcrypt's OFB and they should. [2010-02-26 16:16:56] zelnaga at gmail dot com As far as I know, the IV is also used for the first round, so I am not sure if your statement holds up. Ummm... the IV - as defined in mcrypt_generic_init - is only used in the first round. Per wikipedia, the first block against which the plaintext is XOR'd is the IV encrypted with the key. That's true in both CFB and OFB modes of operation. The difference between CFB and OFB is what subsequent blocks encrypt for the keystream. So, per that, the first block should be the same. And as for my first bug report... ?php $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo urlencode(mcrypt_generic($td, '')); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo urlencode(mcrypt_generic($td, '')); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); ? All of those should produce the same ciphertext. As it stands, only ecb, cbc and ctr produce the same ciphertext. ofb and cfb produce the same thing as each other (and, for the first block, they should, as I already mentioned), however, they're not producing the same thing as any of the other modes when, in fact, they should be. [2010-02-26 10:54:01] der...@php.net As far as I know, the IV is also used for the first round, so I am not sure if your statement holds up.
Bug #52077 [Com]: SNMP GET/WALK may hangs FOREVER
Edit report at http://bugs.php.net/bug.php?id=52077edit=1
ID: 52077
Comment by: wajim at mail dot ru
Reported by: wajim at mail dot ru
Summary: SNMP GET/WALK may hangs FOREVER
Status: Feedback
Type: Bug
Package: SNMP related
Operating System: Win XP SP3
PHP Version: 5.2.13
New Comment:
In net-snmp bugtracker I yet did not write.
Previous Comments:
[2010-06-19 15:31:47] paj...@php.net
did you send a patch to the ucd-snmp maintainers?
If your patch is accepted I can then patch our builds, and it will be
fixed for the next 5.3.x release (can't and won't touch snmp in 5.2
touch).
[2010-06-19 15:13:44] wajim at mail dot ru
static int _sess_read(void *sessp, fd_set *fdset){
[cut]
unsigned long unblock; //WAJIM
[cut]
unblock = 1; ioctlsocket(isp-sd, FIONBIO, unblock); //WAJIM
length = recvfrom(isp-sd, (char *)packet, PACKET_LENGTH, 0, (struct
sockaddr *)from, fromlength);
unblock = 0; ioctlsocket(isp-sd, FIONBIO, unblock); //WAJIM
[cut]
}
Those my 3 lines in snmp_api.c (ucd-snmp-4.2.7.1) fixes threads hanging.
:-)
[2010-06-19 15:03:22] larryjadams at comcast dot net
Stupid WINSock does not support send and receive timeout socket options.
It's a poorly implemented socket api. The net-snmp guys will have to
implement with an alarm. It can not be solved here. But nice catch.
[2010-06-13 21:41:34] wajim at mail dot ru
Description:
Under a heavy GET/WALK-ing (form localhost to localhost) php may hangs
forever - apache's threads becomes zombies with CLOSE_WAIT sates even
all timeouts (php and apache) are elapsed many times.
Call-stack of a one zombie-thread:
ntoskrnl.exe!KiUnlockDispatcherDatabase+0x77
ntoskrnl.exe!KeSetEvent+0x74
ntoskrnl.exe!PspGetSetContextSpecialApc+0x4e
ntoskrnl.exe!KiDeliverApc+0xb3
ntoskrnl.exe!KiSwapThread+0x64
ntoskrnl.exe!KeWaitForSingleObject+0x1c2
ntoskrnl.exe!NtWaitForSingleObject+0x9a
ntoskrnl.exe!KiFastCallEntry+0xf8
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwWaitForSingleObject+0xc
mswsock.dll!SockWaitForSingleObject+0x1a0
mswsock.dll!WSPRecvFrom+0x1f0
WS2_32.dll!recvfrom+0x89
php_snmp.dll!snmp_sess_read+0x21f
php_snmp.dll!snmp_sess_read+0x10
php_snmp.dll!snmp_read+0x17
php_snmp.dll!snmp_synch_response_cb+0xe8
php_snmp.dll!snmp_synch_response+0x19
php_snmp.dll!php_snmp_internal+0x267
php_snmp.dll!php_snmp+0x6da
php_snmp.dll!zif_snmp2_get+0x27
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x7ab
php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER+0xe5
php5ts.dll!execute+0x1c5
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15
php5ts.dll!execute+0x1c5
php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15
php5ts.dll!execute+0x1c5
php5ts.dll!zend_execute_scripts+0x107
php5ts.dll!php_execute_script+0x21d
php5apache.dll!apache_php_module_main+0x91
php5apache.dll!send_php+0x265
php5apache.dll!send_parsed_php+0x10
ApacheCore.dll!ap_invoke_handler+0x87
ApacheCore.dll!ap_process_request+0x2b4
ApacheCore.dll!ap_process_request+0x26
ApacheCore.dll!ap_start_restart+0x37f
WS2_32.dll!WSASocketW+0x119
IMHO bad call WS2_32.dll!recvfrom in buggy ucd-snmp library may hangs.
There are no socket option like setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO,
... before recvfrom call.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52077edit=1
[PHP-BUG] Req #52126 [NEW]: The mail.log added in PHP 5.3.0 has no timestamps.
From: Operating system: CentOS 5 PHP version: 5.3.2 Package: Mail related Bug Type: Feature/Change Request Bug description:The mail.log added in PHP 5.3.0 has no timestamps. Description: The entries in the PHP 5.3.0 and up mail.log have no timestamps. Timestamps would be incredibly useful for multiple reasons including meaningful logwatch reports. -- Edit bug report at http://bugs.php.net/bug.php?id=52126edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52126r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52126r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52126r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52126r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52126r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52126r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52126r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52126r=needscript Try newer version: http://bugs.php.net/fix.php?id=52126r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52126r=support Expected behavior: http://bugs.php.net/fix.php?id=52126r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52126r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52126r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52126r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52126r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52126r=dst IIS Stability: http://bugs.php.net/fix.php?id=52126r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52126r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52126r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52126r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52126r=mysqlcfg
Bug #52123 [Bgs]: strtotim() returns date for one year ago
Edit report at http://bugs.php.net/bug.php?id=52123edit=1
ID: 52123
Updated by: der...@php.net
Reported by: alipendashteh at gmail dot com
Summary: strtotim() returns date for one year ago
Status: Bogus
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
New Comment:
Perhaps, but we can't just change how the parser works. Others might
perhaps rely on this.
Previous Comments:
[2010-06-19 13:10:44] alipendashteh at gmail dot com
Yes; but I meant the default behavior of strtotime() is not appropriate
now.
and i think it is absolutely better that something like 2011, February
8 parses as Y, F j instead of Hi, F j.
[2010-06-19 13:03:52] degeb...@php.net
You already have DateTime::createFromFormat() if you wish to parse other
formats.
[2010-06-19 12:59:36] alipendashteh at gmail dot com
you right; this is not a bug.
but i think the Y, F j is much more common than Hi, F j.
and many application like Drupal use Y, F j as a default date format.
so parsing date as Hi, F j rather than Y, F j would cause confiusing
errors in applications.
I suggest replace the priorities of two format mentioned.
[2010-06-19 11:41:47] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is not a bug. 2011 is seen as time instead:
php -r 'var_dump(date_parse(2011, February 8));'
array(12) {
[year]=
bool(false)
[month]=
int(2)
[day]=
int(8)
[hour]=
int(20)
[minute]=
int(11)
[second]=
int(0)
[fraction]=
bool(false)
[warning_count]=
int(0)
[warnings]=
array(0) {
}
[error_count]=
int(0)
[errors]=
array(0) {
}
[is_localtime]=
bool(false)
}
[2010-06-19 11:22:14] alipendashteh at gmail dot com
Description:
Hi,
strtotime returns wrong date (one year ago) with some formats like:
2011, February 8
Test script:
---
echo (date('Y-m-d', strtotime(2011, February 8)));
Expected result:
2011-02-08
Actual result:
--
2010-02-08
--
Edit this bug report at http://bugs.php.net/bug.php?id=52123edit=1
Bug #52086 [Com]: No new line at the end of a included pool file crahes the PHP FPM daemon
Edit report at http://bugs.php.net/bug.php?id=52086edit=1 ID: 52086 Comment by: admin at saltwaterc dot net Reported by: admin at saltwaterc dot net Summary: No new line at the end of a included pool file crahes the PHP FPM daemon Status: Analyzed Type: Bug Package: FPM related Operating System: * PHP Version: 5.3.2 Assigned To: fat New Comment: service php-fpm restart Gracefully shutting down php-fpm done Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 19 15:50:58.956049 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/default.conf from /usr/local/zend/etc/php-fpm.conf at line 8 Jun 19 15:50:58.956439 [ERROR] failed to load configuration file '/usr/local/zend/etc/php-fpm.conf' failed It doesn't dump the backtrace and the memory map, but it still crashes. I made a PHP script that writes the configuration to /usr/local/zend/etc/fpm.d/: #!/usr/local/zend/bin/php ?php file_put_contents ( /usr/local/zend/etc/fpm.d/default.conf, [default] user = php-fpm group = php-fpm listen = /var/run/php-fpm/default.sock pm = static pm.max_children = 2 pm.max_requests = 1 chdir = /var/www ); This reproduces the bug. If I manually edit the file with nano, everything is fine since nano automatically adds a new line at the end of the last line. Previous Comments: [2010-06-15 17:08:02] f...@php.net Can you try the attached patch please ? [2010-06-15 17:07:25] f...@php.net The following patch has been added/updated: Patch Name: fpm-include.error.patch Revision: 1276614445 URL: http://bugs.php.net/patch-display.php?bug=52086patch=fpm-include.error.patchrevision=1276614445 [2010-06-15 14:49:38] admin at saltwaterc dot net Description: I have a script that automatically generates pool configurations based on input parameters and a template configuration. It didn't used to place a new line at the end of the generated configuration file which degenerated into a hard to debug error as the daemon crashes without any useful explanation. By adding a new line after the last configuration line (in my example, php_admin_value[upload_tmp_dir] = /home/example.com/tmp) everything works as expected. Test script: --- [example.com] user = example.com group = example.com listen = /var/run/php-fpm/example.com.sock pm = static pm.max_children = 2 pm.max_requests = 1 slowlog = /home/example.com/logs/fpm/slow.log chdir = /home/example.com/docroot php_admin_value[error_log] = /home/example.com/logs/fpm/error.log php_admin_value[open_basedir] = /home/example.com/docroot:/home/example.com/sessions:/home/example.com/tmp php_admin_value[session.save_path] = /home/example.com/sessions php_admin_value[upload_tmp_dir] = /home/example.com/tmp Expected result: Successful PHP FPM daemon start. Actual result: -- Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 15 12:35:12.090707 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/example.com.ini from /usr/local/zend/etc/php-fpm.conf at line 23 *** glibc detected *** /usr/local/zend/sbin/php-fpm: double free or corruption (fasttop): 0x1ac80380 *** + backtrace + memory map -- Edit this bug report at http://bugs.php.net/bug.php?id=52086edit=1
Bug #47789 [Com]: Opera file upload - multiple files from one input cannot be handled
Edit report at http://bugs.php.net/bug.php?id=47789edit=1 ID: 47789 Comment by: spamdeja at mail dot ru Reported by: michal dot aichinger at gmail dot com Summary: Opera file upload - multiple files from one input cannot be handled Status: Bogus Type: Bug Package: *General Issues Operating System: Windows / Linux PHP Version: 5.2.9 New Comment: It's true bug of php Previous Comments: [2009-03-31 07:32:34] michal dot aichinger at gmail dot com I am pretty shure that this is bug. PHP does not respect multipart/mixed part in POST request and it is clearly a bug. This part is valid and is made only by Opera in this example. [2009-03-31 07:20:07] j...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2009-03-26 14:33:55] michal dot aichinger at gmail dot com Description: Code below makes form with one file input. In Opera and Safari 4 it is possible select more than one file in this input. If you send this form in Safari it is in PHP normaly handled like multi file upload (multiple inputs). Upload from Opera caused empty $_FILES array. The diference between this browsers is that Opera use multipart/mixed for packing files from this input when posting data. Reproduce code: --- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=cs lang=cs head meta http-equiv=content-type content=text/html; charset=utf-8 titleMultiupload/title /head body h1Multiupload/h1 form action=test.php method=post enctype=multipart/form-data input type=file name=files[] multiple=multiple min=0 max=5 / input type=submit / /form pre ?php print_r($_FILES); ? /pre /body /html Expected result: full $_FILES array after sending more files selected in files[] input from Opera Actual result: -- array is empty -- Edit this bug report at http://bugs.php.net/bug.php?id=47789edit=1
Bug #52086 [Ana-Csd]: No new line at the end of a included pool file crahes the PHP FPM daemon
Edit report at http://bugs.php.net/bug.php?id=52086edit=1 ID: 52086 Updated by: f...@php.net Reported by: admin at saltwaterc dot net Summary: No new line at the end of a included pool file crahes the PHP FPM daemon -Status: Analyzed +Status: Closed Type: Bug Package: FPM related Operating System: * PHP Version: 5.3.2 Assigned To: fat New Comment: 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-06-19 18:31:21] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300604 Log: - Fixed bug #52086 (No new line at the end of a included file crahes the PHP FPM daemon) [2010-06-19 17:58:43] admin at saltwaterc dot net service php-fpm restart Gracefully shutting down php-fpm done Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 19 15:50:58.956049 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/default.conf from /usr/local/zend/etc/php-fpm.conf at line 8 Jun 19 15:50:58.956439 [ERROR] failed to load configuration file '/usr/local/zend/etc/php-fpm.conf' failed It doesn't dump the backtrace and the memory map, but it still crashes. I made a PHP script that writes the configuration to /usr/local/zend/etc/fpm.d/: #!/usr/local/zend/bin/php ?php file_put_contents ( /usr/local/zend/etc/fpm.d/default.conf, [default] user = php-fpm group = php-fpm listen = /var/run/php-fpm/default.sock pm = static pm.max_children = 2 pm.max_requests = 1 chdir = /var/www ); This reproduces the bug. If I manually edit the file with nano, everything is fine since nano automatically adds a new line at the end of the last line. [2010-06-15 17:08:02] f...@php.net Can you try the attached patch please ? [2010-06-15 17:07:25] f...@php.net The following patch has been added/updated: Patch Name: fpm-include.error.patch Revision: 1276614445 URL: http://bugs.php.net/patch-display.php?bug=52086patch=fpm-include.error.patchrevision=1276614445 [2010-06-15 14:49:38] admin at saltwaterc dot net Description: I have a script that automatically generates pool configurations based on input parameters and a template configuration. It didn't used to place a new line at the end of the generated configuration file which degenerated into a hard to debug error as the daemon crashes without any useful explanation. By adding a new line after the last configuration line (in my example, php_admin_value[upload_tmp_dir] = /home/example.com/tmp) everything works as expected. Test script: --- [example.com] user = example.com group = example.com listen = /var/run/php-fpm/example.com.sock pm = static pm.max_children = 2 pm.max_requests = 1 slowlog = /home/example.com/logs/fpm/slow.log chdir = /home/example.com/docroot php_admin_value[error_log] = /home/example.com/logs/fpm/error.log php_admin_value[open_basedir] = /home/example.com/docroot:/home/example.com/sessions:/home/example.com/tmp php_admin_value[session.save_path] = /home/example.com/sessions php_admin_value[upload_tmp_dir] = /home/example.com/tmp Expected result: Successful PHP FPM daemon start. Actual result: -- Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 15 12:35:12.090707 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/example.com.ini from /usr/local/zend/etc/php-fpm.conf at line 23 *** glibc detected *** /usr/local/zend/sbin/php-fpm: double free or corruption (fasttop): 0x1ac80380 *** + backtrace + memory map -- Edit this bug report at http://bugs.php.net/bug.php?id=52086edit=1
Bug #47789 [Com]: Opera file upload - multiple files from one input cannot be handled
Edit report at http://bugs.php.net/bug.php?id=47789edit=1 ID: 47789 Comment by: sowingsadness at gmail dot com Reported by: michal dot aichinger at gmail dot com Summary: Opera file upload - multiple files from one input cannot be handled Status: Bogus Type: Bug Package: *General Issues Operating System: Windows / Linux PHP Version: 5.2.9 New Comment: http://tools.ietf.org/html/rfc1867 3.3 use of multipart/form-data The definition of multipart/form-data is included in section 7. A boundary is selected that does not occur in any of the data. (This selection is sometimes done probabilisticly.) Each field of the form is sent, in the order in which it occurs in the form, as a part of the multipart stream. Each part identifies the INPUT name within the original HTML form. Each part should be labelled with an appropriate content-type if the media type is known (e.g., inferred from the file extension or operating system typing information) or as application/octet-stream. If multiple files are selected, they should be transferred together using the multipart/mixed format. Previous Comments: [2010-06-19 18:28:28] spamdeja at mail dot ru It's true bug of php [2009-03-31 07:32:34] michal dot aichinger at gmail dot com I am pretty shure that this is bug. PHP does not respect multipart/mixed part in POST request and it is clearly a bug. This part is valid and is made only by Opera in this example. [2009-03-31 07:20:07] j...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2009-03-26 14:33:55] michal dot aichinger at gmail dot com Description: Code below makes form with one file input. In Opera and Safari 4 it is possible select more than one file in this input. If you send this form in Safari it is in PHP normaly handled like multi file upload (multiple inputs). Upload from Opera caused empty $_FILES array. The diference between this browsers is that Opera use multipart/mixed for packing files from this input when posting data. Reproduce code: --- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=cs lang=cs head meta http-equiv=content-type content=text/html; charset=utf-8 titleMultiupload/title /head body h1Multiupload/h1 form action=test.php method=post enctype=multipart/form-data input type=file name=files[] multiple=multiple min=0 max=5 / input type=submit / /form pre ?php print_r($_FILES); ? /pre /body /html Expected result: full $_FILES array after sending more files selected in files[] input from Opera Actual result: -- array is empty -- Edit this bug report at http://bugs.php.net/bug.php?id=47789edit=1
Bug #51723 [Csd]: Content-length header is limited to 32bit integer
Edit report at http://bugs.php.net/bug.php?id=51723edit=1 ID: 51723 Updated by: paj...@php.net Reported by: anatoli at adt dot ee Summary: Content-length header is limited to 32bit integer Status: Closed Type: Bug Package: Apache2 related Operating System: vista 32 PHP Version: 5.2.13 Assigned To: pajoye New Comment: See #50940 too. Previous Comments: [2010-05-03 21:52:01] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=298930 Log: - revert fix for #51723 in 5.2, vc6 does not support strtoi64, use builtin functioon in 5.3 (trunk is vc9+ only) [2010-05-03 19:48:08] paj...@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/. Thank you for the report, and for helping us make PHP better. [2010-05-03 10:46:33] paj...@php.net Windows 64bit is not always limited to 32bit if the correct type are used (__int64 co). About unix, that's the same reason. Long is 64bit on 64bit linux while being 32bit on 32bit linux. As I will fix this problem on windows, it won't ever work on 32bit linux, but that's not really an issue as it never worked on these old systems. [2010-05-03 10:40:54] anatoli at adt dot ee Was not able to find 32bit unix/linux system. Tested on 64bit both cgi and apache sapi - working, content-type header data is correct. [2010-05-03 10:31:39] anatoli at adt dot ee Ok, now i got the point. Yes i really missed that long in windows is always 32bit by default and as i remember in 64bit windows it is also limited to 32bit. There must be used long long type, but i am not sure that this is possible. But anyway thanks. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51723 -- Edit this bug report at http://bugs.php.net/bug.php?id=51723edit=1
Bug #52061 [Opn-Csd]: memory_limit above 2G
Edit report at http://bugs.php.net/bug.php?id=52061edit=1
ID: 52061
Updated by: fel...@php.net
Reported by: mail-phpbugs at fushigi dot de
Summary: memory_limit above 2G
-Status: Open
+Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Linux/Centos-5
PHP Version: 5.2SVN-2010-06-12 (snap)
-Assigned To:
+Assigned To: felipe
New Comment:
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-06-19 22:47:27] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300606
Log: - Fixed bug #52061 (memory_limit above 2G)
# MFH: zend_atol()
[2010-06-12 02:56:41] mail-phpbugs at fushigi dot de
Description:
PHP 5.2 doesn't coun't process memory_limit = 2048M in right way
in 32bit mode it works up to 4G, after that it would cause a fatal
error, this seems ok, because of the memory limitations of 32bit :)
in 64bit its a REAL BUG, because after 2047M the memory limit DOESN'T
MATCH, this means no memory limit is active !
as far as i have seen the memory limit for php51 isn't affectet this way
because it walks in an error as of 2GB
and it seems in php53 the problem is fixed, here i tried to set limits
up to 8GB and all worked fine.
The test script is from http://news.php.net/php.internals/48607 , but i
think is shows the problem very well :)
is it possible to fix this, so it will behave as php-5.3 ?
or have the same matching as in 32bit version, so there is a limit if
someone setting a too high value ?
i have found this problem as i wanted to get a customer from an old
php-5.2.13 32bit machine on a newer php-5.2.13 64bit machine :(
32bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
0 - 0.000s:0.1 / 0.2 MB
1 - 1.294s: 166.7 / 177.5 MB
2 - 2.453s: 333.2 / 355.1 MB
3 - 3.988s: 499.7 / 532.4 MB
4 - 5.700s: 666.3 / 709.5 MB
5 - 7.614s: 832.8 / 886.9 MB
6 - 9.838s: 999.3 / 1'064.0 MB
7 - 11.592s:1'165.9 / 1'241.3 MB
8 - 12.943s:1'332.4 / 1'418.6 MB
9 - 19.795s:1'498.9 / 1'595.7 MB
PHP Fatal error: Allowed memory size of -2147483648 bytes exhausted
(tried to allocate 40961 bytes) in /tmp/php-memtest.php on line 32
64bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
0 - 0.000s:0.1 / 0.2 MB
1 - 0.110s: 167.0 / 177.8 MB
2 - 0.221s: 333.8 / 355.1 MB
3 - 0.335s: 500.5 / 532.2 MB
4 - 0.449s: 667.3 / 709.7 MB
5 - 0.560s: 834.1 / 887.1 MB
6 - 0.672s:1'000.9 / 1'064.2 MB
7 - 0.782s:1'167.7 / 1'241.7 MB
8 - 0.891s:1'334.5 / 1'418.8 MB
9 - 1.000s:1'501.3 / 1'596.0 MB
10 - 1.109s:1'668.1 / 1'773.3 MB
11 - 1.219s:1'834.9 / 1'950.4 MB
12 - 1.328s:2'001.7 / 2'127.5 MB
13 - 1.436s:2'168.5 / 2'304.9 MB
14 - 1.543s:2'335.3 / 2'482.2 MB
15 - 1.651s:2'502.1 / 2'659.3 MB
16 - 1.758s:2'668.9 / 2'836.6 MB
17 - 1.864s:2'835.7 / 3'013.7 MB
18 - 1.969s:3'002.5 / 3'190.9 MB
19 - 2.079s:3'169.3 / 3'368.2 MB
20 - 2.189s:3'336.0 / 3'545.5 MB
21 - 2.300s:3'502.8 / 3'722.6 MB
22 - 2.411s:3'669.6 / 3'900.0 MB
23 - 2.519s:3'836.4 / 4'077.1 MB
24 - 2.628s:4'003.2 / 4'254.2 MB
25 - 2.737s:4'170.0 / 4'431.5 MB
26 - 2.845s:4'336.8 / 4'608.6 MB
27 - 2.953s:4'503.6 / 4'786.0 MB
28 - 3.061s:4'670.4 / 4'963.3 MB
29 - 3.169s:4'837.2 / 5'140.4 MB
30 - 3.277s:5'004.0 / 5'317.5 MB
31 - 3.384s:5'170.8 / 5'494.9 MB
32 - 3.490s:5'337.6 / 5'672.0 MB
33 - 3.596s:5'504.4 / 5'849.3 MB
34 - 3.703s:5'671.2 / 6'026.6 MB
35 - 3.809s:5'838.0 / 6'203.7 MB
36 - 3.914s:6'004.8 / 6'380.9 MB
37 - 4.019s:6'171.6 / 6'558.2 MB
38 - 4.124s:6'338.3 / 6'735.3 MB
39 - 4.231s:6'505.1 / 6'912.4 MB
40 - 4.342s:6'671.9 / 7'089.8 MB
Cleaning up 21 output handlers
Done, total time: 4.638s, peak mem: 6'671.9 / 7'089.8 MB
## Other Versions ##
32bit 5.1:
Running 40 times with a 16383 bytes long string
Bug #52061 [Csd-Asn]: memory_limit above 2G
Edit report at http://bugs.php.net/bug.php?id=52061edit=1
ID: 52061
Updated by: fel...@php.net
Reported by: mail-phpbugs at fushigi dot de
Summary: memory_limit above 2G
-Status: Closed
+Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Linux/Centos-5
PHP Version: 5.2SVN-2010-06-12 (snap)
-Assigned To: felipe
+Assigned To: pajoye
Previous Comments:
[2010-06-19 22:48:39] fel...@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/.
Thank you for the report, and for helping us make PHP better.
[2010-06-19 22:47:27] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300606
Log: - Fixed bug #52061 (memory_limit above 2G)
# MFH: zend_atol()
[2010-06-12 02:56:41] mail-phpbugs at fushigi dot de
Description:
PHP 5.2 doesn't coun't process memory_limit = 2048M in right way
in 32bit mode it works up to 4G, after that it would cause a fatal
error, this seems ok, because of the memory limitations of 32bit :)
in 64bit its a REAL BUG, because after 2047M the memory limit DOESN'T
MATCH, this means no memory limit is active !
as far as i have seen the memory limit for php51 isn't affectet this way
because it walks in an error as of 2GB
and it seems in php53 the problem is fixed, here i tried to set limits
up to 8GB and all worked fine.
The test script is from http://news.php.net/php.internals/48607 , but i
think is shows the problem very well :)
is it possible to fix this, so it will behave as php-5.3 ?
or have the same matching as in 32bit version, so there is a limit if
someone setting a too high value ?
i have found this problem as i wanted to get a customer from an old
php-5.2.13 32bit machine on a newer php-5.2.13 64bit machine :(
32bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
0 - 0.000s:0.1 / 0.2 MB
1 - 1.294s: 166.7 / 177.5 MB
2 - 2.453s: 333.2 / 355.1 MB
3 - 3.988s: 499.7 / 532.4 MB
4 - 5.700s: 666.3 / 709.5 MB
5 - 7.614s: 832.8 / 886.9 MB
6 - 9.838s: 999.3 / 1'064.0 MB
7 - 11.592s:1'165.9 / 1'241.3 MB
8 - 12.943s:1'332.4 / 1'418.6 MB
9 - 19.795s:1'498.9 / 1'595.7 MB
PHP Fatal error: Allowed memory size of -2147483648 bytes exhausted
(tried to allocate 40961 bytes) in /tmp/php-memtest.php on line 32
64bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
0 - 0.000s:0.1 / 0.2 MB
1 - 0.110s: 167.0 / 177.8 MB
2 - 0.221s: 333.8 / 355.1 MB
3 - 0.335s: 500.5 / 532.2 MB
4 - 0.449s: 667.3 / 709.7 MB
5 - 0.560s: 834.1 / 887.1 MB
6 - 0.672s:1'000.9 / 1'064.2 MB
7 - 0.782s:1'167.7 / 1'241.7 MB
8 - 0.891s:1'334.5 / 1'418.8 MB
9 - 1.000s:1'501.3 / 1'596.0 MB
10 - 1.109s:1'668.1 / 1'773.3 MB
11 - 1.219s:1'834.9 / 1'950.4 MB
12 - 1.328s:2'001.7 / 2'127.5 MB
13 - 1.436s:2'168.5 / 2'304.9 MB
14 - 1.543s:2'335.3 / 2'482.2 MB
15 - 1.651s:2'502.1 / 2'659.3 MB
16 - 1.758s:2'668.9 / 2'836.6 MB
17 - 1.864s:2'835.7 / 3'013.7 MB
18 - 1.969s:3'002.5 / 3'190.9 MB
19 - 2.079s:3'169.3 / 3'368.2 MB
20 - 2.189s:3'336.0 / 3'545.5 MB
21 - 2.300s:3'502.8 / 3'722.6 MB
22 - 2.411s:3'669.6 / 3'900.0 MB
23 - 2.519s:3'836.4 / 4'077.1 MB
24 - 2.628s:4'003.2 / 4'254.2 MB
25 - 2.737s:4'170.0 / 4'431.5 MB
26 - 2.845s:4'336.8 / 4'608.6 MB
27 - 2.953s:4'503.6 / 4'786.0 MB
28 - 3.061s:4'670.4 / 4'963.3 MB
29 - 3.169s:4'837.2 / 5'140.4 MB
30 - 3.277s:5'004.0 / 5'317.5 MB
31 - 3.384s:5'170.8 / 5'494.9 MB
32 - 3.490s:5'337.6 / 5'672.0 MB
33 - 3.596s:5'504.4 / 5'849.3 MB
34 - 3.703s:5'671.2 / 6'026.6 MB
35 - 3.809s:5'838.0 / 6'203.7 MB
36 - 3.914s:6'004.8 / 6'380.9 MB
37 - 4.019s:6'171.6 / 6'558.2 MB
38 - 4.124s:6'338.3 / 6'735.3 MB
39 - 4.231s:6'505.1 / 6'912.4 MB
40 - 4.342s:6'671.9 / 7'089.8 MB
Cleaning up 21 output handlers
Done, total time: 4.638s, peak mem: 6'671.9 / 7'089.8 MB
Bug #52120 [Opn-Fbk]: Unable to call inherited protected __construct
Edit report at http://bugs.php.net/bug.php?id=52120edit=1
ID: 52120
Updated by: fel...@php.net
Reported by: vr...@php.net
Summary: Unable to call inherited protected __construct
-Status: Open
+Status: Feedback
Type: Bug
-Package: Class/Object related
+Package: Scripting Engine problem
Operating System: *
PHP Version: 5.3.2
New Comment:
This is true for all methods except __construct().
Can you provide an test case for non __construct method? I cannot
reproduce it.
Previous Comments:
[2010-06-18 17:15:42] vr...@php.net
Description:
Protected visibility allows accessing parent members and also members of
parent's children. If class A defines protected method f() and classes B
and C are children of A then B can call C::f(). This is true for all
methods except __construct().
Test script:
---
class A {
protected function __construct() {
}
}
class B extends A {
static function test() {
new C;
}
}
class C extends A {
protected function __construct() {
echo OK\n;
}
}
B::test();
Expected result:
OK
Actual result:
--
Fatal error: Call to protected C::__construct() from context 'B' on line
9
--
Edit this bug report at http://bugs.php.net/bug.php?id=52120edit=1
Bug #52108 [Opn-Bgs]: PHP-Bug in Array Key
Edit report at http://bugs.php.net/bug.php?id=52108edit=1
ID: 52108
Updated by: fel...@php.net
Reported by: goebel at arsmedia-software dot de
Summary: PHP-Bug in Array Key
-Status: Open
+Status: Bogus
Type: Bug
Package: JSON related
Operating System: Ubuntu 9.04 (AMD64)
PHP Version: Irrelevant
New Comment:
See bug #45959
Previous Comments:
[2010-06-19 12:26:41] anon at anon dot com
Hi, just passing by. I don't know why it does that but here's a more
complete test that does not require JSON:
error_reporting(-1);
//$obj = json_decode('{2:123}');
$obj = new stdClass();
$obj-{2} = 123;
var_dump($obj-{2}, $obj-{2}, $obj);
$array = (array)$obj;
var_dump($array[2], $array[2], $array);
It can access the int(123) via both 2 and 2 on the object, but even
though the array var_dump shows the 2 key to be present, and it can be
iterated, both [2] and [2] complain the offset/index is undefined.
[2010-06-17 10:19:21] goebel at arsmedia-software dot de
Description:
Hello,
I've found an error in the keys of an array. If I have a JSON-String and
decode it with json_decode and cast the returned value in an array then
I get NULL trying to access an array entry (eg array[1]). The return
value should however be a stdClass object.
Yours sincerely,
Arne Göbel
Test script:
---
$jstr = '{1: {anzahl: , preis: , einheit: ,
beschreibung: , mwst: }, 2: {anzahl: 22, preis: 3,
einheit: , beschreibung: , mwst: }, 3: {anzahl: 12,
preis: 22, einheit: , beschreibung: , mwst: }, 4:
{anzahl: , preis: , einheit: , beschreibung: , mwst:
}}';
$array = (array) json_decode($jstr);
echo 'pre';
var_dump($array[2], $array);
echo phpversion();
Expected result:
array(
2 = stdClass object
public anzahl = 22
public preis = 3
public einheit =
public beschreibung =
public mwst =
)
Actual result:
--
NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=52108edit=1
Bug #52010 [Csd]: open_basedir restrictions mismatch on vacuum command
Edit report at http://bugs.php.net/bug.php?id=52010edit=1
ID: 52010
User updated by: hajo at csphere dot eu
Reported by: hajo at csphere dot eu
Summary: open_basedir restrictions mismatch on vacuum command
Status: Closed
Type: Bug
Package: SQLite related
Operating System: Windows (any)
PHP Version: 5.3.2
Assigned To: iliaa
New Comment:
version 5.3.3 fixes this for sqlite3, but pdo_sqlite still has this bug
error message says the authorization is denied
Previous Comments:
[2010-06-09 18:05:04] il...@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/.
Thank you for the report, and for helping us make PHP better.
[2010-06-09 18:04:56] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300318
Log: Fixed bug #52010 (open_basedir restrictions mismatch on vacuum
command).
[2010-06-06 21:52:47] hajo at csphere dot eu
corrected summary
[2010-06-06 21:51:23] hajo at csphere dot eu
Description:
with open_basedir enabled and an sqlite3 database file within one of
these allowed directories - using the sqlite3 extension - the sql
command vacuum insert_tablename_here triggers an open_basedir
restriction error.
what confuses the most is that File() in the error message seems to be
empty every time this error occurs and i haven't discovered such
behavior in similar problems.
pdo_sqlite extension is also affected, sqlite3 lib version is 3.6.22
Test script:
---
$sqlite3-query('vacuum anytable');
Expected result:
no error returned
Actual result:
--
PHP-Warning: Warning: SQLite3::query() [sqlite3.query]: open_basedir
restriction in effect. File() is not within the allowed path(s): (a lot
of paths listed in here) in test.php on line 77
PHP-Warning: Warning: SQLite3::query() [sqlite3.query]: Unable to
execute statement: not authorized in test.php on line 77
--
Edit this bug report at http://bugs.php.net/bug.php?id=52010edit=1
Bug #49020 [Com]: phar misinterprets ustar long filename standard
Edit report at http://bugs.php.net/bug.php?id=49020edit=1 ID: 49020 Comment by: lanangkasmaran at yahoo dot co dot id Reported by: cel...@php.net Summary: phar misinterprets ustar long filename standard Status: Closed Type:Bug Package: PHAR related PHP Version: 5.3.0 Assigned To: cellog New Comment: http://nekobudi77.com/ Previous Comments: [2009-07-22 20:14:55] cel...@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/. Thank you for the report, and for helping us make PHP better. [2009-07-22 19:09:27] cel...@php.net Description: the phar implementation of long filenames splits on the 100th character no matter what, but the ustar standard specifies that the split should be on a directory boundary -- Edit this bug report at http://bugs.php.net/bug.php?id=49020edit=1
Bug #49020 [Com]: phar misinterprets ustar long filename standard
Edit report at http://bugs.php.net/bug.php?id=49020edit=1 ID: 49020 Comment by: lanangkasmaran at yahoo dot co dot id Reported by: cel...@php.net Summary: phar misinterprets ustar long filename standard Status: Closed Type:Bug Package: PHAR related PHP Version: 5.3.0 Assigned To: cellog New Comment: http://nekobudi77.wordpress.com/ Previous Comments: [2010-06-20 03:16:58] lanangkasmaran at yahoo dot co dot id http://nekobudi77.com/ [2009-07-22 20:14:55] cel...@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/. Thank you for the report, and for helping us make PHP better. [2009-07-22 19:09:27] cel...@php.net Description: the phar implementation of long filenames splits on the 100th character no matter what, but the ustar standard specifies that the split should be on a directory boundary -- Edit this bug report at http://bugs.php.net/bug.php?id=49020edit=1
