Bug #54058 [Opn-Csd]: json_last_error() doesn't work properly with arrays/objects
Edit report at http://bugs.php.net/bug.php?id=54058edit=1
ID: 54058
Updated by: scott...@php.net
Reported by:slusarz at curecanti dot org
Summary:json_last_error() doesn't work properly with
arrays/objects
-Status: Open
+Status: Closed
Type: Bug
Package:JSON related
Operating System: Linux
PHP Version:5.3.5
-Assigned To:
+Assigned To:scottmac
Block user comment: N
Private report: N
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:
[2011-02-21 09:09:04] scott...@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=308529
Log: Fix Bug #54058, invalid utf-8 doesn't set json_encode() in all
cases
[2011-02-21 07:05:47] slusarz at curecanti dot org
Description:
json_last_error() doesn't work properly in arrays/objects. If an error
occurs when encoding a property/key, and it isn't the LAST property/key,
json_last_error() is reset to 0.
json_last_error() should report the last parsing error from the last
json_encode() call AS AN ENTIRETY, not the last internal encoding step
that takes place inside the function.
Test script:
---
$bad_utf8 = quoted_printable_decode('=B0');
json_encode($bad_utf8);
print ERROR: . json_last_error() . \n;
$a = new stdclass;
$a-foo = quoted_printable_decode('=B0');
json_encode($a);
print ERROR: . json_last_error() . \n;
$b = new stdclass;
$b-foo = $bad_utf8;
$b-bar = 1;
json_encode($b);
print ERROR: . json_last_error() . \n;
$c = array(
'foo' = $bad_utf8,
'bar' = 1
);
json_encode($c);
print ERROR: . json_last_error() . \n;
Expected result:
ERROR: 5
ERROR: 5
ERROR: 5
ERROR: 5
Actual result:
--
ERROR: 5
ERROR: 5
ERROR: 0
ERROR: 0
--
Edit this bug report at http://bugs.php.net/bug.php?id=54058edit=1
[PHP-BUG] Bug #54060 [NEW]: Memory leaks when openssl_encrypt called
From:
Operating system: Linux, Any
PHP version: 5.3SVN-2011-02-21 (snap)
Package: OpenSSL related
Bug Type: Bug
Bug description:Memory leaks when openssl_encrypt called
Description:
Memory leaks when I call openssl_encrypt. Test script shows that. I've
watch at ext/openssl/openssl.c and according to
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html (see example at the
bottom) you should free cipher_ctx. So I've put
EVP_CIPHER_CTX_cleanup(cipher_ctx);
at line 4722 before
RETVAL_STRINGL(base64_str, base64_str_len, 0);
Recompile php (make make install) and after start test
(mem_non_leaks.log) I have decreaced memory leakes. It's seems, it's not
compleate patch
With memory leakes:
valgrind --log-file=mem_eak.log --leak-check=full ~/php5.3/bin/php -d
extension=openssl.so crypt_test_openssl.php
Report:
==31035== 76,713,600 bytes in 199,775 blocks are definitely lost in loss
record 128 of 128
==31035==at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==31035==by 0x35670DAD91: CRYPTO_malloc (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x35670D9450: EVP_CipherInit_ex (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x861079C: ???
==31035==by 0x76BED1: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:316)
==31035==by 0x771E17: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1606)
==31035==by 0x76AEED: execute (zend_vm_execute.h:107)
==31035==by 0x737E93: zend_execute_scripts (zend.c:1194)
==31035==by 0x6B72E5: php_execute_script (main.c:2268)
==31035==by 0x82AFA7: main (php_cli.c:1193)
==31035==
==31035== LEAK SUMMARY:
==31035==definitely lost: 76,713,984 bytes in 199,776 blocks
==31035==indirectly lost: 0 bytes in 0 blocks
==31035== possibly lost: 74,880 bytes in 195 blocks
==31035==still reachable: 100,809 bytes in 1,688 blocks
==31035== suppressed: 0 bytes in 0 blocks
Almost without memory leaks:
valgrind --log-file=mem_non_leaks.log --leak-check=full
/home/dovbyshko/php5.3/bin/php -d extension=openssl.so
crypt_test_openssl.php
==19014== LEAK SUMMARY:
==19014==definitely lost: 384 bytes in 1 blocks
==19014==indirectly lost: 0 bytes in 0 blocks
==19014== possibly lost: 0 bytes in 0 blocks
==19014==still reachable: 88,905 bytes in 1,657 blocks
==19014== suppressed: 0 bytes in 0 blocks
Test script:
---
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy ruy
972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
--
Edit bug report at http://bugs.php.net/bug.php?id=54060edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54060r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54060r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54060r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54060r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54060r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54060r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54060r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54060r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54060r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54060r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54060r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54060r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54060r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54060r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54060r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54060r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54060r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54060r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54060r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54060r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54060r=mysqlcfg
Bug #54060 [Opn-Asn]: Memory leaks when openssl_encrypt called
Edit report at http://bugs.php.net/bug.php?id=54060edit=1
ID: 54060
Updated by: paj...@php.net
Reported by:dovbysh at gmail dot com
Summary:Memory leaks when openssl_encrypt called
-Status: Open
+Status: Assigned
Type: Bug
Package:OpenSSL related
Operating System: Linux, Any
PHP Version:5.3SVN-2011-02-21 (snap)
Block user comment: N
Private report: N
New Comment:
verified, patch on its way.
Previous Comments:
[2011-02-21 09:16:10] dovbysh at gmail dot com
Description:
Memory leaks when I call openssl_encrypt. Test script shows that. I've
watch at ext/openssl/openssl.c and according to
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html (see example at
the bottom) you should free cipher_ctx. So I've put
EVP_CIPHER_CTX_cleanup(cipher_ctx);
at line 4722 before
RETVAL_STRINGL(base64_str, base64_str_len, 0);
Recompile php (make make install) and after start test
(mem_non_leaks.log) I have decreaced memory leakes. It's seems, it's not
compleate patch
With memory leakes:
valgrind --log-file=mem_eak.log --leak-check=full ~/php5.3/bin/php -d
extension=openssl.so crypt_test_openssl.php
Report:
==31035== 76,713,600 bytes in 199,775 blocks are definitely lost in loss
record 128 of 128
==31035==at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==31035==by 0x35670DAD91: CRYPTO_malloc (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x35670D9450: EVP_CipherInit_ex (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x861079C: ???
==31035==by 0x76BED1: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:316)
==31035==by 0x771E17: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1606)
==31035==by 0x76AEED: execute (zend_vm_execute.h:107)
==31035==by 0x737E93: zend_execute_scripts (zend.c:1194)
==31035==by 0x6B72E5: php_execute_script (main.c:2268)
==31035==by 0x82AFA7: main (php_cli.c:1193)
==31035==
==31035== LEAK SUMMARY:
==31035==definitely lost: 76,713,984 bytes in 199,776 blocks
==31035==indirectly lost: 0 bytes in 0 blocks
==31035== possibly lost: 74,880 bytes in 195 blocks
==31035==still reachable: 100,809 bytes in 1,688 blocks
==31035== suppressed: 0 bytes in 0 blocks
Almost without memory leaks:
valgrind --log-file=mem_non_leaks.log --leak-check=full
/home/dovbyshko/php5.3/bin/php -d extension=openssl.so
crypt_test_openssl.php
==19014== LEAK SUMMARY:
==19014==definitely lost: 384 bytes in 1 blocks
==19014==indirectly lost: 0 bytes in 0 blocks
==19014== possibly lost: 0 bytes in 0 blocks
==19014==still reachable: 88,905 bytes in 1,657 blocks
==19014== suppressed: 0 bytes in 0 blocks
Test script:
---
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
--
Edit this bug report at http://bugs.php.net/bug.php?id=54060edit=1
Bug #54060 [Opn-Csd]: Memory leaks when openssl_encrypt called
Edit report at http://bugs.php.net/bug.php?id=54060edit=1
ID: 54060
Updated by: paj...@php.net
Reported by:dovbysh at gmail dot com
Summary:Memory leaks when openssl_encrypt called
-Status: Open
+Status: Closed
Type: Bug
Package:OpenSSL related
Operating System: Linux, Any
PHP Version:5.3SVN-2011-02-21 (snap)
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Private report: N
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:
[2011-02-21 11:07:33] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=308531
Log: - fix bug #54060, memory leak in openssl_encrypt
[2011-02-21 10:48:43] paj...@php.net
verified, patch on its way.
[2011-02-21 09:16:10] dovbysh at gmail dot com
Description:
Memory leaks when I call openssl_encrypt. Test script shows that. I've
watch at ext/openssl/openssl.c and according to
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html (see example at
the bottom) you should free cipher_ctx. So I've put
EVP_CIPHER_CTX_cleanup(cipher_ctx);
at line 4722 before
RETVAL_STRINGL(base64_str, base64_str_len, 0);
Recompile php (make make install) and after start test
(mem_non_leaks.log) I have decreaced memory leakes. It's seems, it's not
compleate patch
With memory leakes:
valgrind --log-file=mem_eak.log --leak-check=full ~/php5.3/bin/php -d
extension=openssl.so crypt_test_openssl.php
Report:
==31035== 76,713,600 bytes in 199,775 blocks are definitely lost in loss
record 128 of 128
==31035==at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==31035==by 0x35670DAD91: CRYPTO_malloc (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x35670D9450: EVP_CipherInit_ex (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x861079C: ???
==31035==by 0x76BED1: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:316)
==31035==by 0x771E17: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1606)
==31035==by 0x76AEED: execute (zend_vm_execute.h:107)
==31035==by 0x737E93: zend_execute_scripts (zend.c:1194)
==31035==by 0x6B72E5: php_execute_script (main.c:2268)
==31035==by 0x82AFA7: main (php_cli.c:1193)
==31035==
==31035== LEAK SUMMARY:
==31035==definitely lost: 76,713,984 bytes in 199,776 blocks
==31035==indirectly lost: 0 bytes in 0 blocks
==31035== possibly lost: 74,880 bytes in 195 blocks
==31035==still reachable: 100,809 bytes in 1,688 blocks
==31035== suppressed: 0 bytes in 0 blocks
Almost without memory leaks:
valgrind --log-file=mem_non_leaks.log --leak-check=full
/home/dovbyshko/php5.3/bin/php -d extension=openssl.so
crypt_test_openssl.php
==19014== LEAK SUMMARY:
==19014==definitely lost: 384 bytes in 1 blocks
==19014==indirectly lost: 0 bytes in 0 blocks
==19014== possibly lost: 0 bytes in 0 blocks
==19014==still reachable: 88,905 bytes in 1,657 blocks
==19014== suppressed: 0 bytes in 0 blocks
Test script:
---
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
--
Edit this bug report at http://bugs.php.net/bug.php?id=54060edit=1
Bug #54060 [Csd-Asn]: Memory leaks when openssl_encrypt called
Edit report at http://bugs.php.net/bug.php?id=54060edit=1
ID: 54060
User updated by:dovbysh at gmail dot com
Reported by:dovbysh at gmail dot com
Summary:Memory leaks when openssl_encrypt called
-Status: Closed
+Status: Assigned
Type: Bug
Package:OpenSSL related
-Operating System:
+Operating System: Any
PHP Version:5.3SVN-2011-02-21 (snap)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
openssl_decrypt appears this bug too...
test script:
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
$cr = openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
$dcr = openssl_decrypt($cr, 'des3', $pass, false, '1qazxsw2');
if ($dcr != $data.$i){
print at step $i decryption failed\n;
}
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
?
fixes by add this code at line 4818 at the end of openssl_decrypt:
EVP_CIPHER_CTX_cleanup(cipher_ctx);
Previous Comments:
[2011-02-21 11:07:49] 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.
[2011-02-21 11:07:33] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=308531
Log: - fix bug #54060, memory leak in openssl_encrypt
[2011-02-21 10:48:43] paj...@php.net
verified, patch on its way.
[2011-02-21 09:16:10] dovbysh at gmail dot com
Description:
Memory leaks when I call openssl_encrypt. Test script shows that. I've
watch at ext/openssl/openssl.c and according to
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html (see example at
the bottom) you should free cipher_ctx. So I've put
EVP_CIPHER_CTX_cleanup(cipher_ctx);
at line 4722 before
RETVAL_STRINGL(base64_str, base64_str_len, 0);
Recompile php (make make install) and after start test
(mem_non_leaks.log) I have decreaced memory leakes. It's seems, it's not
compleate patch
With memory leakes:
valgrind --log-file=mem_eak.log --leak-check=full ~/php5.3/bin/php -d
extension=openssl.so crypt_test_openssl.php
Report:
==31035== 76,713,600 bytes in 199,775 blocks are definitely lost in loss
record 128 of 128
==31035==at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==31035==by 0x35670DAD91: CRYPTO_malloc (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x35670D9450: EVP_CipherInit_ex (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x861079C: ???
==31035==by 0x76BED1: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:316)
==31035==by 0x771E17: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1606)
==31035==by 0x76AEED: execute (zend_vm_execute.h:107)
==31035==by 0x737E93: zend_execute_scripts (zend.c:1194)
==31035==by 0x6B72E5: php_execute_script (main.c:2268)
==31035==by 0x82AFA7: main (php_cli.c:1193)
==31035==
==31035== LEAK SUMMARY:
==31035==definitely lost: 76,713,984 bytes in 199,776 blocks
==31035==indirectly lost: 0 bytes in 0 blocks
==31035== possibly lost: 74,880 bytes in 195 blocks
==31035==still reachable: 100,809 bytes in 1,688 blocks
==31035== suppressed: 0 bytes in 0 blocks
Almost without memory leaks:
valgrind --log-file=mem_non_leaks.log --leak-check=full
/home/dovbyshko/php5.3/bin/php -d extension=openssl.so
crypt_test_openssl.php
==19014== LEAK SUMMARY:
==19014==definitely lost: 384 bytes in 1 blocks
==19014==indirectly lost: 0 bytes in 0 blocks
==19014== possibly lost: 0 bytes in 0 blocks
==19014==still reachable: 88,905 bytes in 1,657 blocks
==19014== suppressed: 0 bytes in 0 blocks
Test script:
---
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
Bug #54060 [Asn-Csd]: Memory leaks when openssl_encrypt called
Edit report at http://bugs.php.net/bug.php?id=54060edit=1
ID: 54060
Updated by: paj...@php.net
Reported by:dovbysh at gmail dot com
Summary:Memory leaks when openssl_encrypt called
-Status: Assigned
+Status: Closed
Type: Bug
Package:OpenSSL related
Operating System: Any
PHP Version:5.3SVN-2011-02-21 (snap)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Please open a new bug for decrypt.
Also you don't need a loop to reproduce the leak, one run is enough :)
Previous Comments:
[2011-02-21 12:45:59] dovbysh at gmail dot com
openssl_decrypt appears this bug too...
test script:
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
$cr = openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
$dcr = openssl_decrypt($cr, 'des3', $pass, false, '1qazxsw2');
if ($dcr != $data.$i){
print at step $i decryption failed\n;
}
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
?
fixes by add this code at line 4818 at the end of openssl_decrypt:
EVP_CIPHER_CTX_cleanup(cipher_ctx);
[2011-02-21 11:07:49] 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.
[2011-02-21 11:07:33] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=308531
Log: - fix bug #54060, memory leak in openssl_encrypt
[2011-02-21 10:48:43] paj...@php.net
verified, patch on its way.
[2011-02-21 09:16:10] dovbysh at gmail dot com
Description:
Memory leaks when I call openssl_encrypt. Test script shows that. I've
watch at ext/openssl/openssl.c and according to
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html (see example at
the bottom) you should free cipher_ctx. So I've put
EVP_CIPHER_CTX_cleanup(cipher_ctx);
at line 4722 before
RETVAL_STRINGL(base64_str, base64_str_len, 0);
Recompile php (make make install) and after start test
(mem_non_leaks.log) I have decreaced memory leakes. It's seems, it's not
compleate patch
With memory leakes:
valgrind --log-file=mem_eak.log --leak-check=full ~/php5.3/bin/php -d
extension=openssl.so crypt_test_openssl.php
Report:
==31035== 76,713,600 bytes in 199,775 blocks are definitely lost in loss
record 128 of 128
==31035==at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==31035==by 0x35670DAD91: CRYPTO_malloc (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x35670D9450: EVP_CipherInit_ex (in
/lib64/libcrypto.so.0.9.8e)
==31035==by 0x861079C: ???
==31035==by 0x76BED1: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:316)
==31035==by 0x771E17: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1606)
==31035==by 0x76AEED: execute (zend_vm_execute.h:107)
==31035==by 0x737E93: zend_execute_scripts (zend.c:1194)
==31035==by 0x6B72E5: php_execute_script (main.c:2268)
==31035==by 0x82AFA7: main (php_cli.c:1193)
==31035==
==31035== LEAK SUMMARY:
==31035==definitely lost: 76,713,984 bytes in 199,776 blocks
==31035==indirectly lost: 0 bytes in 0 blocks
==31035== possibly lost: 74,880 bytes in 195 blocks
==31035==still reachable: 100,809 bytes in 1,688 blocks
==31035== suppressed: 0 bytes in 0 blocks
Almost without memory leaks:
valgrind --log-file=mem_non_leaks.log --leak-check=full
/home/dovbyshko/php5.3/bin/php -d extension=openssl.so
crypt_test_openssl.php
==19014== LEAK SUMMARY:
==19014==definitely lost: 384 bytes in 1 blocks
==19014==indirectly lost: 0 bytes in 0 blocks
==19014== possibly lost: 0 bytes in 0 blocks
==19014==still reachable: 88,905 bytes in 1,657 blocks
==19014== suppressed: 0 bytes in 0 blocks
Test script:
---
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for
[PHP-BUG] Bug #54061 [NEW]: Memory leaks when openssl_encrypt called
From:
Operating system: Linux, Any
PHP version: 5.3SVN-2011-02-21 (snap)
Package: OpenSSL related
Bug Type: Bug
Bug description:Memory leaks when openssl_encrypt called
Description:
Related bug #54060, http://bugs.php.net/bug.php?id=54060
Memory leaks when I call openssl_decrypt. Test script shows that. I've
watch at ext/openssl/openssl.c and according to
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html (see example at the
bottom) you should free cipher_ctx.
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy ruy
972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
$cr = openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
$dcr = openssl_decrypt($cr, 'des3', $pass, false, '1qazxsw2');
if ($dcr != $data.$i){
print at step $i decryption failed\n;
}
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
?
fixes by add this code at line 4818 at the end of openssl_decrypt:
EVP_CIPHER_CTX_cleanup(cipher_ctx);
--
Edit bug report at http://bugs.php.net/bug.php?id=54061edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54061r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54061r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54061r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54061r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54061r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54061r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54061r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54061r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54061r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54061r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54061r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54061r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54061r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54061r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54061r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54061r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54061r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54061r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54061r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54061r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54061r=mysqlcfg
Bug #54060 [Csd]: Memory leaks when openssl_encrypt called
Edit report at http://bugs.php.net/bug.php?id=54060edit=1
ID: 54060
User updated by:dovbysh at gmail dot com
Reported by:dovbysh at gmail dot com
Summary:Memory leaks when openssl_encrypt called
Status: Closed
Type: Bug
Package:OpenSSL related
Operating System: Any
PHP Version:5.3SVN-2011-02-21 (snap)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I've open Bug #54061.
Previous Comments:
[2011-02-21 12:51:41] paj...@php.net
Please open a new bug for decrypt.
Also you don't need a loop to reproduce the leak, one run is enough :)
[2011-02-21 12:45:59] dovbysh at gmail dot com
openssl_decrypt appears this bug too...
test script:
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
$cr = openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
$dcr = openssl_decrypt($cr, 'des3', $pass, false, '1qazxsw2');
if ($dcr != $data.$i){
print at step $i decryption failed\n;
}
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
?
fixes by add this code at line 4818 at the end of openssl_decrypt:
EVP_CIPHER_CTX_cleanup(cipher_ctx);
[2011-02-21 11:07:49] 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.
[2011-02-21 11:07:33] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=308531
Log: - fix bug #54060, memory leak in openssl_encrypt
[2011-02-21 10:48:43] paj...@php.net
verified, patch on its way.
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=54060
--
Edit this bug report at http://bugs.php.net/bug.php?id=54060edit=1
[PHP-BUG] Bug #54062 [NEW]: PHP does not notice user abort
From:
Operating system: Linux/Windows
PHP version: Irrelevant
Package: Network related
Bug Type: Bug
Bug description:PHP does not notice user abort
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called should
the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function which
says the user is still connected, despite my pressing the browser stop
button immediately after placing the request.
I have tested this on Windows using Lighttpd with PHP 5.2, and on Ubuntu
with Apache preforking PHP 5.3. Both exhibit the same behaviour.
These tests were conducted with ignore_user_abort(true) and (false) - no
difference observed so I removed it.
Test script:
---
?php
syslog(LOG_DEBUG, 'Connection opened');
register_shutdown_function('shutdown');
$usleep = 200;
for ($i=0; $i 100; $i++) {
$str[$i] = '';
for ($x=0; $x 1000; $x++) {
$str[$i] .= 'flubber';
}
}
if (isset($_REQUEST['usleep'])) {
$usleep = (int) $_REQUEST['usleep'];
}
usleep($usleep);
syslog(LOG_DEBUG, 'Completed usleep()');
echo Thanks for waiting\n;
print_r($str);
ob_end_flush();
syslog(LOG_DEBUG, 'ob_end_flush() called');
flush();
syslog(LOG_DEBUG, 'Have flushed()');
// We get to this part regardless of having already pressed STOP
function shutdown()
{
echo Thanks for waiting\n;
flush();
syslog(LOG_DEBUG, 'Echo completed');
//sleep(1);
syslog(LOG_DEBUG, 'Have slept');
syslog(LOG_DEBUG, 'Shutdown detected.');
syslog(LOG_DEBUG, The result of connection_status() is: .
connection_status());
// The above is almost always 0
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
// This almost always happens!
syslog(LOG_DEBUG, 'The connection remains');
}
}
Expected result:
syslog entries should stop when PHP writes to the client socket and notes
that the client has sent an abort signal. Then, the shutdown function
should show that the connection_status() is no longer 0, and that the
connection_aborted() method returns true.
Actual result:
--
syslog entries continue to Have flushed(), then show that The result of
connection_status() is: 0. and The connection remains.
This should not be the case. Perhaps Apache is not sending the appropriate
signal, yet neither is Lighttpd..?
--
Edit bug report at http://bugs.php.net/bug.php?id=54062edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54062r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54062r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54062r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54062r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54062r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54062r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54062r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54062r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54062r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54062r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54062r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54062r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54062r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54062r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54062r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54062r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54062r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54062r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54062r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54062r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54062r=mysqlcfg
Bug #54061 [Opn-Csd]: Memory leaks when openssl_encrypt called
Edit report at http://bugs.php.net/bug.php?id=54061edit=1
ID: 54061
Updated by: paj...@php.net
Reported by:dovbysh at gmail dot com
Summary:Memory leaks when openssl_encrypt called
-Status: Open
+Status: Closed
Type: Bug
Package:OpenSSL related
Operating System: Linux, Any
PHP Version:5.3SVN-2011-02-21 (snap)
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Fixed by http://svn.php.net/viewvc?view=revisionrevision=308535
Previous Comments:
[2011-02-21 12:59:10] dovbysh at gmail dot com
Description:
Related bug #54060, http://bugs.php.net/bug.php?id=54060
Memory leaks when I call openssl_decrypt. Test script shows that. I've
watch at ext/openssl/openssl.c and according to
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html (see example at
the bottom) you should free cipher_ctx.
?php
$data = jfdslkjvflsdkjvlkfjvlkjfvlkdm,4w 043920r 9234r 32904r 09243
r7-89437 r892374 r894372 r894 7289r7 f frwerfh i iurf iuryw uyrfouiwy
ruy 972439 8478942 yrhfjkdhls;
$pass = r23498rui324hjbnkj;
$maxi = 20;
$t = microtime(1);
for ($i=0;$i$maxi; $i++){
$cr = openssl_encrypt($data.$i, 'des3', $pass, false, '1qazxsw2');
$dcr = openssl_decrypt($cr, 'des3', $pass, false, '1qazxsw2');
if ($dcr != $data.$i){
print at step $i decryption failed\n;
}
}
$t = microtime(1)-$t;
print mode: openssl_encrypt ($maxi) tests takes .$t.secs
.($maxi/$t).#/sec \n;
?
fixes by add this code at line 4818 at the end of openssl_decrypt:
EVP_CIPHER_CTX_cleanup(cipher_ctx);
--
Edit this bug report at http://bugs.php.net/bug.php?id=54061edit=1
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: ceo at l-i-e dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
Previous Comments:
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called
should the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function
which says the user is still connected, despite my pressing the browser
stop button immediately after placing the request.
I have tested this on Windows using Lighttpd with PHP 5.2, and on Ubuntu
with Apache preforking PHP 5.3. Both exhibit the same behaviour.
These tests were conducted with ignore_user_abort(true) and (false) - no
difference observed so I removed it.
Test script:
---
?php
syslog(LOG_DEBUG, 'Connection opened');
register_shutdown_function('shutdown');
$usleep = 200;
for ($i=0; $i 100; $i++) {
$str[$i] = '';
for ($x=0; $x 1000; $x++) {
$str[$i] .= 'flubber';
}
}
if (isset($_REQUEST['usleep'])) {
$usleep = (int) $_REQUEST['usleep'];
}
usleep($usleep);
syslog(LOG_DEBUG, 'Completed usleep()');
echo Thanks for waiting\n;
print_r($str);
ob_end_flush();
syslog(LOG_DEBUG, 'ob_end_flush() called');
flush();
syslog(LOG_DEBUG, 'Have flushed()');
// We get to this part regardless of having already pressed STOP
function shutdown()
{
echo Thanks for waiting\n;
flush();
syslog(LOG_DEBUG, 'Echo completed');
//sleep(1);
syslog(LOG_DEBUG, 'Have slept');
syslog(LOG_DEBUG, 'Shutdown detected.');
syslog(LOG_DEBUG, The result of connection_status() is: .
connection_status());
// The above is almost always 0
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
// This almost always happens!
syslog(LOG_DEBUG, 'The connection remains');
}
}
Expected result:
syslog entries should stop when PHP writes to the client socket and
notes that the client has sent an abort signal. Then, the shutdown
function should show that the connection_status() is no longer 0, and
that the connection_aborted() method returns true.
Actual result:
--
syslog entries continue to Have flushed(), then show that The result of
connection_status() is: 0. and The connection remains.
This should not be the case. Perhaps Apache is not sending the
appropriate signal, yet neither is Lighttpd..?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
Previous Comments:
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called
should the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function
which says the user is still connected, despite my pressing the browser
stop button immediately after placing the request.
I have tested this on Windows using Lighttpd with PHP 5.2, and on Ubuntu
with Apache preforking PHP 5.3. Both exhibit the same behaviour.
These tests were conducted with ignore_user_abort(true) and (false) - no
difference observed so I removed it.
Test script:
---
?php
syslog(LOG_DEBUG, 'Connection opened');
register_shutdown_function('shutdown');
$usleep = 200;
for ($i=0; $i 100; $i++) {
$str[$i] = '';
for ($x=0; $x 1000; $x++) {
$str[$i] .= 'flubber';
}
}
if (isset($_REQUEST['usleep'])) {
$usleep = (int) $_REQUEST['usleep'];
}
usleep($usleep);
syslog(LOG_DEBUG, 'Completed usleep()');
echo Thanks for waiting\n;
print_r($str);
ob_end_flush();
syslog(LOG_DEBUG, 'ob_end_flush() called');
flush();
syslog(LOG_DEBUG, 'Have flushed()');
// We get to this part regardless of having already pressed STOP
function shutdown()
{
echo Thanks for waiting\n;
flush();
syslog(LOG_DEBUG, 'Echo completed');
//sleep(1);
syslog(LOG_DEBUG, 'Have slept');
syslog(LOG_DEBUG, 'Shutdown detected.');
syslog(LOG_DEBUG, The result of connection_status() is: .
connection_status());
// The above is almost always 0
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
// This almost always happens!
syslog(LOG_DEBUG, 'The connection remains');
}
}
Expected result:
syslog entries should stop when PHP writes to the client socket and
notes that the client has sent an abort signal. Then, the shutdown
function should show that the connection_status() is no longer 0, and
that the connection_aborted() method returns true.
Actual result:
--
syslog entries continue to Have flushed(), then show that The result of
connection_status() is: 0. and The connection remains.
This should not be the case. Perhaps Apache is not sending the
appropriate signal, yet neither is Lighttpd..?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Bug #54062 [Opn]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Updated by: cataphr...@php.net
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Works fine here:
Normal circumstances:
Feb 21 16:06:33 damnation apache2: Connection opened
Feb 21 16:06:35 damnation apache2: Completed usleep()
Feb 21 16:06:35 damnation apache2: ob_end_flush() called
Feb 21 16:06:35 damnation apache2: Have flushed()
Feb 21 16:06:35 damnation apache2: Echo completed
Feb 21 16:06:35 damnation apache2: Have slept
Feb 21 16:06:35 damnation apache2: Shutdown detected.
Feb 21 16:06:35 damnation apache2: The result of connection_status() is:
0
Feb 21 16:06:35 damnation apache2: The connection remains
Stop button:
Feb 21 16:06:44 damnation apache2: Connection opened
Feb 21 16:06:46 damnation apache2: Completed usleep()
Feb 21 16:06:46 damnation apache2: ob_end_flush() called
Feb 21 16:06:46 damnation apache2: Have flushed()
ignore_user_abort(true) + Stop button:
Feb 21 16:07:59 damnation apache2: Connection opened
Feb 21 16:08:01 damnation apache2: Completed usleep()
Feb 21 16:08:01 damnation apache2: ob_end_flush() called
Feb 21 16:08:01 damnation apache2: Have flushed()
Feb 21 16:08:01 damnation apache2: Echo completed
Feb 21 16:08:01 damnation apache2: Have slept
Feb 21 16:08:01 damnation apache2: Shutdown detected.
Feb 21 16:08:01 damnation apache2: The result of connection_status() is:
1
Feb 21 16:08:01 damnation apache2: The connection has aborted
(Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16)
Previous Comments:
[2011-02-21 16:50:09] james dot mk dot green at gmail dot com
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called
should the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function
which says the user is still connected, despite my pressing the browser
stop button immediately after placing the request.
I have tested this on Windows using Lighttpd with PHP 5.2, and on Ubuntu
with Apache preforking PHP 5.3. Both exhibit the same behaviour.
These tests were conducted with ignore_user_abort(true) and (false) - no
difference observed so I removed it.
Test script:
---
?php
syslog(LOG_DEBUG, 'Connection opened');
register_shutdown_function('shutdown');
$usleep = 200;
for ($i=0; $i 100; $i++) {
$str[$i] = '';
for ($x=0; $x 1000; $x++) {
$str[$i] .= 'flubber';
}
}
if (isset($_REQUEST['usleep'])) {
$usleep = (int) $_REQUEST['usleep'];
}
usleep($usleep);
syslog(LOG_DEBUG, 'Completed usleep()');
echo Thanks for waiting\n;
print_r($str);
ob_end_flush();
syslog(LOG_DEBUG, 'ob_end_flush() called');
flush();
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
Previous Comments:
[2011-02-21 17:11:06] cataphr...@php.net
Works fine here:
Normal circumstances:
Feb 21 16:06:33 damnation apache2: Connection opened
Feb 21 16:06:35 damnation apache2: Completed usleep()
Feb 21 16:06:35 damnation apache2: ob_end_flush() called
Feb 21 16:06:35 damnation apache2: Have flushed()
Feb 21 16:06:35 damnation apache2: Echo completed
Feb 21 16:06:35 damnation apache2: Have slept
Feb 21 16:06:35 damnation apache2: Shutdown detected.
Feb 21 16:06:35 damnation apache2: The result of connection_status() is:
0
Feb 21 16:06:35 damnation apache2: The connection remains
Stop button:
Feb 21 16:06:44 damnation apache2: Connection opened
Feb 21 16:06:46 damnation apache2: Completed usleep()
Feb 21 16:06:46 damnation apache2: ob_end_flush() called
Feb 21 16:06:46 damnation apache2: Have flushed()
ignore_user_abort(true) + Stop button:
Feb 21 16:07:59 damnation apache2: Connection opened
Feb 21 16:08:01 damnation apache2: Completed usleep()
Feb 21 16:08:01 damnation apache2: ob_end_flush() called
Feb 21 16:08:01 damnation apache2: Have flushed()
Feb 21 16:08:01 damnation apache2: Echo completed
Feb 21 16:08:01 damnation apache2: Have slept
Feb 21 16:08:01 damnation apache2: Shutdown detected.
Feb 21 16:08:01 damnation apache2: The result of connection_status() is:
1
Feb 21 16:08:01 damnation apache2: The connection has aborted
(Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16)
[2011-02-21 16:50:09] james dot mk dot green at gmail dot com
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called
should the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function
which says
Bug #54062 [Opn-Fbk]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Updated by: johan...@php.net
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
-Status: Open
+Status: Feedback
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please use vanilla PHP from php.net. We have no idea what kind of
patches Ubuntu applies and what they might break.
Previous Comments:
[2011-02-21 17:31:59] james dot mk dot green at gmail dot com
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
[2011-02-21 17:11:06] cataphr...@php.net
Works fine here:
Normal circumstances:
Feb 21 16:06:33 damnation apache2: Connection opened
Feb 21 16:06:35 damnation apache2: Completed usleep()
Feb 21 16:06:35 damnation apache2: ob_end_flush() called
Feb 21 16:06:35 damnation apache2: Have flushed()
Feb 21 16:06:35 damnation apache2: Echo completed
Feb 21 16:06:35 damnation apache2: Have slept
Feb 21 16:06:35 damnation apache2: Shutdown detected.
Feb 21 16:06:35 damnation apache2: The result of connection_status() is:
0
Feb 21 16:06:35 damnation apache2: The connection remains
Stop button:
Feb 21 16:06:44 damnation apache2: Connection opened
Feb 21 16:06:46 damnation apache2: Completed usleep()
Feb 21 16:06:46 damnation apache2: ob_end_flush() called
Feb 21 16:06:46 damnation apache2: Have flushed()
ignore_user_abort(true) + Stop button:
Feb 21 16:07:59 damnation apache2: Connection opened
Feb 21 16:08:01 damnation apache2: Completed usleep()
Feb 21 16:08:01 damnation apache2: ob_end_flush() called
Feb 21 16:08:01 damnation apache2: Have flushed()
Feb 21 16:08:01 damnation apache2: Echo completed
Feb 21 16:08:01 damnation apache2: Have slept
Feb 21 16:08:01 damnation apache2: Shutdown detected.
Feb 21 16:08:01 damnation apache2: The result of connection_status() is:
1
Feb 21 16:08:01 damnation apache2: The connection has aborted
(Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16)
[2011-02-21 16:50:09] james dot mk dot green at gmail dot com
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Feedback
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
johannes, it's been tested on a Windows server too (same behaviour).
Besides, cataphract seems to be using Ubuntu's PHP package too.
Perhaps it's something to do with web server configuration? I'm using
CGI on Windows, and mod_php on Ubuntu (Apache Prefork MPM). What might
cause this behaviour?
Previous Comments:
[2011-02-21 17:39:22] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please use vanilla PHP from php.net. We have no idea what kind of
patches Ubuntu applies and what they might break.
[2011-02-21 17:31:59] james dot mk dot green at gmail dot com
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
[2011-02-21 17:11:06] cataphr...@php.net
Works fine here:
Normal circumstances:
Feb 21 16:06:33 damnation apache2: Connection opened
Feb 21 16:06:35 damnation apache2: Completed usleep()
Feb 21 16:06:35 damnation apache2: ob_end_flush() called
Feb 21 16:06:35 damnation apache2: Have flushed()
Feb 21 16:06:35 damnation apache2: Echo completed
Feb 21 16:06:35 damnation apache2: Have slept
Feb 21 16:06:35 damnation apache2: Shutdown detected.
Feb 21 16:06:35 damnation apache2: The result of connection_status() is:
0
Feb 21 16:06:35 damnation apache2: The connection remains
Stop button:
Feb 21 16:06:44 damnation apache2: Connection opened
Feb 21 16:06:46 damnation apache2: Completed usleep()
Feb 21 16:06:46 damnation apache2: ob_end_flush() called
Feb 21 16:06:46 damnation apache2: Have flushed()
ignore_user_abort(true) + Stop button:
Feb 21 16:07:59 damnation apache2: Connection opened
Feb 21 16:08:01 damnation apache2: Completed usleep()
Feb 21 16:08:01 damnation apache2: ob_end_flush() called
Feb 21 16:08:01 damnation apache2: Have flushed()
Feb 21 16:08:01 damnation apache2: Echo completed
Feb 21 16:08:01 damnation apache2: Have slept
Feb 21 16:08:01 damnation apache2: Shutdown detected.
Feb 21 16:08:01 damnation apache2: The result of connection_status() is:
1
Feb 21 16:08:01 damnation apache2: The connection has aborted
(Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16)
[2011-02-21 16:50:09] james dot mk dot green at gmail dot com
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit
Bug #54062 [Fbk]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1 ID: 54062 Updated by: ras...@php.net Reported by:james dot mk dot green at gmail dot com Summary:PHP does not notice user abort Status: Feedback Type: Bug Package:Network related Operating System: Linux/Windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Works fine for me on a Debian box running mod_php with Apache prefork, and a Centos box running nginx and php-fpm. Previous Comments: [2011-02-21 17:42:42] james dot mk dot green at gmail dot com johannes, it's been tested on a Windows server too (same behaviour). Besides, cataphract seems to be using Ubuntu's PHP package too. Perhaps it's something to do with web server configuration? I'm using CGI on Windows, and mod_php on Ubuntu (Apache Prefork MPM). What might cause this behaviour? [2011-02-21 17:39:22] johan...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Please use vanilla PHP from php.net. We have no idea what kind of patches Ubuntu applies and what they might break. [2011-02-21 17:31:59] james dot mk dot green at gmail dot com Feb 21 16:28:57 blofeld apache2: The connection remains Feb 21 16:29:41 blofeld apache2: Connection opened Feb 21 16:29:43 blofeld apache2: Completed usleep() Feb 21 16:29:43 blofeld apache2: ob_end_flush() called Feb 21 16:29:43 blofeld apache2: Have flushed() Feb 21 16:29:43 blofeld apache2: Echo completed Feb 21 16:29:43 blofeld apache2: Have slept Feb 21 16:29:43 blofeld apache2: Shutdown detected. Feb 21 16:29:43 blofeld apache2: The result of connection_status() is: 0 Feb 21 16:29:43 blofeld apache2: The connection remains That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache 2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10. All I do is type in the url of my disconnect.php, hit enter then immediately hit the stop button. [2011-02-21 17:11:06] cataphr...@php.net Works fine here: Normal circumstances: Feb 21 16:06:33 damnation apache2: Connection opened Feb 21 16:06:35 damnation apache2: Completed usleep() Feb 21 16:06:35 damnation apache2: ob_end_flush() called Feb 21 16:06:35 damnation apache2: Have flushed() Feb 21 16:06:35 damnation apache2: Echo completed Feb 21 16:06:35 damnation apache2: Have slept Feb 21 16:06:35 damnation apache2: Shutdown detected. Feb 21 16:06:35 damnation apache2: The result of connection_status() is: 0 Feb 21 16:06:35 damnation apache2: The connection remains Stop button: Feb 21 16:06:44 damnation apache2: Connection opened Feb 21 16:06:46 damnation apache2: Completed usleep() Feb 21 16:06:46 damnation apache2: ob_end_flush() called Feb 21 16:06:46 damnation apache2: Have flushed() ignore_user_abort(true) + Stop button: Feb 21 16:07:59 damnation apache2: Connection opened Feb 21 16:08:01 damnation apache2: Completed usleep() Feb 21 16:08:01 damnation apache2: ob_end_flush() called Feb 21 16:08:01 damnation apache2: Have flushed() Feb 21 16:08:01 damnation apache2: Echo completed Feb 21 16:08:01 damnation apache2: Have slept Feb 21 16:08:01 damnation apache2: Shutdown detected. Feb 21 16:08:01 damnation apache2: The result of connection_status() is: 1 Feb 21 16:08:01 damnation apache2: The connection has aborted (Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16) [2011-02-21 16:50:09] james dot mk dot green at gmail dot com The script attached is a test case. The real script that triggered this report does not use sleep or similar. And yes, on two-three attempts out of several dozen I have seen a client has aborted message. However, statistically this is beyond unreliable. Further to the original report I have spoken in ##php on Freenode and tried their suggestions without any luck. The real script does quite a lot of backend processing while a software client waits. If the client then times out waiting, the server script continues to send back the data processed and says that the client remains connected at the very end (within the shutdown callback). This led me to my testing of connection handling and this test case. 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=54062 -- Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412edit=1
ID: 52412
Comment by: php dot net at phrozenbyte dot de
Reported by:madboyka at yahoo dot com
Summary:__autoload fails to throw exception when calling a
static method on the class
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
I support this re-opening-request... Since 5.3 __autoload() is definitly
*not* the last line of defense for PHP to find a class definition.
That's simply wrong.
http://www.php.net/manual/en/language.oop5.autoload.php (Note #1 +
Example #3)
http://www.php.net/manual/en/language.oop5.changelog.php (#5)
Previous Comments:
[2011-02-19 23:06:12] michael at squiloople dot com
Here's a request to re-open the bug, for it is indeed a bug: exceptions
can be
thrown and caught if the method called is _not_ static, as documented,
but cannot
be thrown and caught if the method _is_ static (and where the class name
is not a
variable), which is both inconsistent and against the documentation. It
is
_unexpected_ behaviour.
[2011-02-16 15:31:49] madboyka at yahoo dot com
To: der...@php.net
I don't think you've read the documentation on autoloading yourself:
http://www.php.net/manual/en/language.oop5.autoload.php
The first note states that since PHP 5.3, you may throw an exception
from the autoload function (even if the class can be loaded) and catch
that exception without a problem. Examples #3 and #4 in the
documentation entry demonstrate this. This works when the autoload
function gets invoked when instantiating a class, but doesn't when you
make a static call on it. This behavior is not consistent.
Also, take a look at michael@...'s workaround, which unexpectedly works
great. And don't tell me that PHP behaves as expected.
I understand, that this is not a major bug, we all can live without a
fix, but at least mark it as to be fixed in the far future.
[2011-02-16 11:24:38] 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
FWIW, this is expected. The __autoload() method is the last line of
defense for PHP to find a class definition. If it can't find it, PHP
bails out with a fatal error. If you throw an exception, you basically
abort this final chance, and thus gives PHP you that fatal can not find
class error. However, you can catch the exception in the __autoload()
method,
[2011-02-16 08:05:14] michael at squiloople dot com
There's a slight hack of a solution tested using PHP 5.3.5 and Windows
Vista:
use a variable as the class name:
function __autoload($class)
{
if (!include $class . '.php')
{
throw new Exception('Cannot autoload ' . $class);
}
}
$class = 'Application';
try
{
$class::start();
}
catch (Exception $e)
{
echo $e-getMessage();
}
// Outputs the exception as expected.
[2010-09-25 23:39:25] alex dot offshore at gmail dot com
Temporary solution.
Caveats and notices:
- The class actually WILL BE DEFINED ANYWAY;
- 'eval' usage;
- __callStatic used to avoid method not found error.
?php
function __autoload($className)
{
echo Want to load $className.\n;
// assuming we can not load class
// error handling code
{
eval('class ' . $className . ' { static function __callStatic($n,
$a) { return false; } }');
throw new Exception(Unable to load $className.);
}
}
try
{
//new MissingClass(); // works as expected
MissingClass::someFunction();
}
catch (Exception $e)
{
echo 'CAUGHT: ' . $e-getMessage(), \n;
}
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=52412
--
Edit this bug report at http://bugs.php.net/bug.php?id=52412edit=1
Bug #54062 [Fbk]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Updated by: ras...@php.net
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Feedback
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
By the way, why so complicated a test?
Try the simple case:
?php
ignore_user_abort(false);
for($i=0;$i1000;$i++) {
sleep(1);
$str = Line $i\n;
echo $str;
flush();
file_put_contents(/tmp/heartbeat.log, $str, FILE_APPEND);
}
Things that might get in the way of this working for you would be if you
have
some sort of reverse proxy cache in front of your web server. Like a
Cloudflare,
for example. Or your own setup. You could also have multiple levels of
output
buffering going on. You could check that case with an ob_get_level()
call.
Previous Comments:
[2011-02-21 19:21:05] ras...@php.net
Works fine for me on a Debian box running mod_php with Apache prefork,
and a
Centos box running nginx and php-fpm.
[2011-02-21 17:42:42] james dot mk dot green at gmail dot com
johannes, it's been tested on a Windows server too (same behaviour).
Besides, cataphract seems to be using Ubuntu's PHP package too.
Perhaps it's something to do with web server configuration? I'm using
CGI on Windows, and mod_php on Ubuntu (Apache Prefork MPM). What might
cause this behaviour?
[2011-02-21 17:39:22] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please use vanilla PHP from php.net. We have no idea what kind of
patches Ubuntu applies and what they might break.
[2011-02-21 17:31:59] james dot mk dot green at gmail dot com
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
[2011-02-21 17:11:06] cataphr...@php.net
Works fine here:
Normal circumstances:
Feb 21 16:06:33 damnation apache2: Connection opened
Feb 21 16:06:35 damnation apache2: Completed usleep()
Feb 21 16:06:35 damnation apache2: ob_end_flush() called
Feb 21 16:06:35 damnation apache2: Have flushed()
Feb 21 16:06:35 damnation apache2: Echo completed
Feb 21 16:06:35 damnation apache2: Have slept
Feb 21 16:06:35 damnation apache2: Shutdown detected.
Feb 21 16:06:35 damnation apache2: The result of connection_status() is:
0
Feb 21 16:06:35 damnation apache2: The connection remains
Stop button:
Feb 21 16:06:44 damnation apache2: Connection opened
Feb 21 16:06:46 damnation apache2: Completed usleep()
Feb 21 16:06:46 damnation apache2: ob_end_flush() called
Feb 21 16:06:46 damnation apache2: Have flushed()
ignore_user_abort(true) + Stop button:
Feb 21 16:07:59 damnation apache2: Connection opened
Feb 21 16:08:01 damnation apache2: Completed usleep()
Feb 21 16:08:01 damnation apache2: ob_end_flush() called
Feb 21 16:08:01 damnation apache2: Have flushed()
Feb 21 16:08:01 damnation apache2: Echo completed
Feb 21 16:08:01 damnation apache2: Have slept
Feb 21 16:08:01 damnation apache2: Shutdown detected.
Feb 21 16:08:01 damnation apache2: The result of connection_status() is:
1
Feb 21 16:08:01 damnation apache2: The connection has aborted
(Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16)
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=54062
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Req #44330 [Opn-Bgs]: Apache with PHP 5+6
Edit report at http://bugs.php.net/bug.php?id=44330edit=1 ID: 44330 Updated by: j...@php.net Reported by:lunter at interia dot pl Summary:Apache with PHP 5+6 -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: only Win PHP Version:6CVS-2008-03-04 (CVS) Block user comment: N Private report: N New Comment: There is no PHP 6 anymore. Previous Comments: [2008-03-04 20:26:34] lunter at interia dot pl To switch beetwen PHP5 and PHP6 you must use .htaccess file: 1) AddType application/x-httpd-php .php # for PHP5 (if not defined in httpd.conf) 2) AddType application/x-httpd-php6 .php # for PHP6 [2008-03-04 20:21:32] lunter at interia dot pl Better idea - compile two dll's in future PHP6: 1) php6apache2_2.dll - current without changes; 2) php6apache2_2c.dll - corrected for admins who want to running Apache2.x with PHP5 PHP6 as module at the same time. [2008-03-04 20:08:44] lunter at interia dot pl sorry - replace: 'application/x-httpd-php' = 'application/x-httpd-php6' Testes with modified php6apache2_2.dll. Works very good. [2008-03-04 19:49:22] lunter at interia dot pl Description: Only Windows php6apache2_2.dll replace: 'PHPINIDir' = 'PHPINIDir6' add second type: 'application/x-httpd-php6' to able load both as Apache module: 1) php5apache2_2.dll 2) php6apache2_2.dll with different Configuration File (php.ini) Path. Expected result: running Apache2.x with PHP5 PHP6 as module at the same time Actual result: -- It is not able to load Apache2.x with PHP5 PHP6 as module. -- Edit this bug report at http://bugs.php.net/bug.php?id=44330edit=1
Req #15184 [Com]: Calculate the quarter with date('Q')?
Edit report at http://bugs.php.net/bug.php?id=15184edit=1
ID: 15184
Comment by: fernandojmartin at gmail dot com
Reported by:j-f at gmx dot net
Summary:Calculate the quarter with date('Q')?
Status: Wont fix
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: -
PHP Version:4.1.1
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Why not to just follow the way MySQL behaves?
In that way I'm not obligated to calculate part of the date OUTSIDE the
DB server!
The YEAR starts on Jan 1st. Period.
The first week of the year has nothing to do with Q1 if the real date is
December
31.
I don't see a clear sustenance in derick's explanation.
Previous Comments:
[2005-08-12 08:46:49] der...@php.net
Some people have different opinions on when the quarter starts. Just
saying that it starts at january 1 is in correct, as most people start
Q1 in the first week of the year or something. That's why I don't think
we should add this.
[2005-08-11 19:22:39] nlop...@php.net
One more for you, Derick :)
[2002-01-23 11:44:26] j-f at gmx dot net
I added a note how to calculate the quarter:
ceil(date('n')/3);
But I suggest extending date() with the option 'Q' or 'q'.
--
Edit this bug report at http://bugs.php.net/bug.php?id=15184edit=1
[PHP-BUG] Req #54066 [NEW]: Add possibility to reflect on a file not loaded in memory
From:
Operating system: Any
PHP version: 5.3.5
Package: Reflection related
Bug Type: Feature/Change Request
Bug description:Add possibility to reflect on a file not loaded in memory
Description:
I'd like to see a ReflectionFile class added to the Reflection api that
would allow you to reflect on the content of a file instead of a loaded
information.
The reason for this can be varied but in my current case is to reflect the
class and code information inside of a file to display to a user. I'm
building a web IDE that will display the class information of a file in a
web project. I don't want to load that file because it could be a security
issue and launch code that i don't want to launch.
Other uses for this is to validate that a file contains a specific class or
reflect on the classes in the file to find if the classes do implement an
interface or a specific class without having to load the code into
execution space.
Finaly, if a file contains non encapsulated code that could be executed
when including the file, the ReflectionFile class could be used to detect
that and you could refuse using the class file. For example, a whiz tries
to place a statement hidden between two class definitions that could
compromise your application, then you could detect it with:
if($myReflectedFile-hasExecutableStatements()){
//Refuse usage of this file
}else{
include($myReflectedFile-filename);
}
The number of implications for this class are large, they allow many other
options such as documentation extraction from a code file. Many of us are
aware that if bytecode caching is active on a server you won't be able to
detect document comments, reading it from the file instead from the memory
could allow many more comment extraction to be possible.
--
Edit bug report at http://bugs.php.net/bug.php?id=54066edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54066r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54066r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54066r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54066r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54066r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54066r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54066r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54066r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54066r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54066r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54066r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54066r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54066r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54066r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54066r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54066r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54066r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54066r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54066r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54066r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54066r=mysqlcfg
Bug #31510 [Com]: sqlite_key function only exists as method for SQLiteResult class
Edit report at http://bugs.php.net/bug.php?id=31510edit=1 ID: 31510 Comment by: php at trafex dot nl Reported by:irch...@php.net Summary:sqlite_key function only exists as method for SQLiteResult class Status: Wont fix Type: Bug Package:SQLite related PHP Version:* Assigned To:helly Block user comment: N Private report: N New Comment: Maybe the documentation should be updated, it doesn't mention any of this. Previous Comments: [2005-04-12 23:14:01] he...@php.net All QLite maintainers decided there is little to no usa in that function. The reason there is SQLiteResult::key() is only because SQLiteResult implements Iterator. [2005-01-12 09:31:58] irch...@php.net Description: The function sqlite_key (line 2637 of ext/sqlite/sqlite.c) only exists as a mapped method of the SQLiteResult class and cannot be used a a procedural function as it has no entry in the sqlite_funcs function table (even though the function has support for being called as such). All that's needed is an entry in sqlite_functions[]. -- Edit this bug report at http://bugs.php.net/bug.php?id=31510edit=1
Bug #31510 [Wfx]: sqlite_key function only exists as method for SQLiteResult class
Edit report at http://bugs.php.net/bug.php?id=31510edit=1 ID: 31510 Updated by: danbr...@php.net Reported by:irch...@php.net Summary:sqlite_key function only exists as method for SQLiteResult class Status: Wont fix Type: Bug Package:SQLite related PHP Version:* Assigned To:helly Block user comment: N Private report: N New Comment: Please submit that as a documentation bug, don't append it to a bug that hasn't been touched in six years or by a complaint in the user notes --- it's not as likely to be noticed and repaired this way. A new submission, however, is very likely to see the documentation corrected pretty soon after submission. Previous Comments: [2011-02-21 22:13:05] php at trafex dot nl Maybe the documentation should be updated, it doesn't mention any of this. [2005-04-12 23:14:01] he...@php.net All QLite maintainers decided there is little to no usa in that function. The reason there is SQLiteResult::key() is only because SQLiteResult implements Iterator. [2005-01-12 09:31:58] irch...@php.net Description: The function sqlite_key (line 2637 of ext/sqlite/sqlite.c) only exists as a mapped method of the SQLiteResult class and cannot be used a a procedural function as it has no entry in the sqlite_funcs function table (even though the function has support for being called as such). All that's needed is an entry in sqlite_functions[]. -- Edit this bug report at http://bugs.php.net/bug.php?id=31510edit=1
Bug #54062 [Fbk-Opn]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
User updated by:james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
-Status: Feedback
+Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
As unlikely as it sounds this may be an issue within Firefox.
I pasted the code from Rasmus onto the web server next door to mine.
Fired it up
in Firefox and PHP detected the user abort. Repeated my script but again
it did
not work. Slowly I worked the code from Rasmus directly in to my script
but
still no joy. At this point all that was different was the name of the
shutdown
function. Then tried using wget as the client and both scripts work.
Repeated
Rasmus' script from Firefox and it no longer detected user abort.
So we have a bug within the client - as far as I can tell. I am least
happy I
can work with this, thanks for all the tests and sorry for wasting
people's
time!
Previous Comments:
[2011-02-21 19:40:41] ras...@php.net
By the way, why so complicated a test?
Try the simple case:
?php
ignore_user_abort(false);
for($i=0;$i1000;$i++) {
sleep(1);
$str = Line $i\n;
echo $str;
flush();
file_put_contents(/tmp/heartbeat.log, $str, FILE_APPEND);
}
Things that might get in the way of this working for you would be if you
have
some sort of reverse proxy cache in front of your web server. Like a
Cloudflare,
for example. Or your own setup. You could also have multiple levels of
output
buffering going on. You could check that case with an ob_get_level()
call.
[2011-02-21 19:21:05] ras...@php.net
Works fine for me on a Debian box running mod_php with Apache prefork,
and a
Centos box running nginx and php-fpm.
[2011-02-21 17:42:42] james dot mk dot green at gmail dot com
johannes, it's been tested on a Windows server too (same behaviour).
Besides, cataphract seems to be using Ubuntu's PHP package too.
Perhaps it's something to do with web server configuration? I'm using
CGI on Windows, and mod_php on Ubuntu (Apache Prefork MPM). What might
cause this behaviour?
[2011-02-21 17:39:22] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please use vanilla PHP from php.net. We have no idea what kind of
patches Ubuntu applies and what they might break.
[2011-02-21 17:31:59] james dot mk dot green at gmail dot com
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
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=54062
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Bug #54062 [Opn-Bgs]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Updated by: johan...@php.net
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
-Status: Open
+Status: Bogus
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Marking bug as user error.
Previous Comments:
[2011-02-21 22:46:08] james dot mk dot green at gmail dot com
As unlikely as it sounds this may be an issue within Firefox.
I pasted the code from Rasmus onto the web server next door to mine.
Fired it up
in Firefox and PHP detected the user abort. Repeated my script but again
it did
not work. Slowly I worked the code from Rasmus directly in to my script
but
still no joy. At this point all that was different was the name of the
shutdown
function. Then tried using wget as the client and both scripts work.
Repeated
Rasmus' script from Firefox and it no longer detected user abort.
So we have a bug within the client - as far as I can tell. I am least
happy I
can work with this, thanks for all the tests and sorry for wasting
people's
time!
[2011-02-21 19:40:41] ras...@php.net
By the way, why so complicated a test?
Try the simple case:
?php
ignore_user_abort(false);
for($i=0;$i1000;$i++) {
sleep(1);
$str = Line $i\n;
echo $str;
flush();
file_put_contents(/tmp/heartbeat.log, $str, FILE_APPEND);
}
Things that might get in the way of this working for you would be if you
have
some sort of reverse proxy cache in front of your web server. Like a
Cloudflare,
for example. Or your own setup. You could also have multiple levels of
output
buffering going on. You could check that case with an ob_get_level()
call.
[2011-02-21 19:21:05] ras...@php.net
Works fine for me on a Debian box running mod_php with Apache prefork,
and a
Centos box running nginx and php-fpm.
[2011-02-21 17:42:42] james dot mk dot green at gmail dot com
johannes, it's been tested on a Windows server too (same behaviour).
Besides, cataphract seems to be using Ubuntu's PHP package too.
Perhaps it's something to do with web server configuration? I'm using
CGI on Windows, and mod_php on Ubuntu (Apache Prefork MPM). What might
cause this behaviour?
[2011-02-21 17:39:22] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please use vanilla PHP from php.net. We have no idea what kind of
patches Ubuntu applies and what they might break.
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=54062
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Bug #53724 [Com]: array_diff like methods compares false as identity and true as equal
Edit report at http://bugs.php.net/bug.php?id=53724edit=1
ID: 53724
Comment by: lukas dot starecek at centrum dot cz
Reported by:lukas dot starecek at centrum dot cz
Summary:array_diff like methods compares false as identity
and true as equal
Status: Open
Type: Bug
Package:Arrays related
Operating System: Irrelevant
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Ah I did not noticed this grey part of method documentation in
examples. You are right, documentation says it, but imho in not so clear
way. I have read only specifications, not examples. Imho documentation
could be a little bit more exact, because this is important.
So sadly this functions are designed only for string comparison, not for
general variable comparison :-/ .
My fault, bogus, sorry. But think about functions of this kind for
general variables comparison, not only for string comparison :-) .
Previous Comments:
[2011-02-20 16:20:18] tbrasta at gmail dot com
This is not a bug. The function is operating exactly as stated in the
documentation, i.e. casted to string values are compared. Since (string)
0 = 0, (string) false = and (string) 0 = 0 but 0 !== , you
get the result as it should be.
[2011-01-12 14:27:34] lukas dot starecek at centrum dot cz
A little mistake, '' behaves as same with false, so problem is only in
comparing 0 and '0' (and maybee some other variables I did not used).
[2011-01-12 14:16:39] lukas dot starecek at centrum dot cz
Description:
array_diff functions compares boolean false as identity (operator ===)
and boolean true as equal (operator ==) so behaves inconsistently. It
should compare all values in same way and in my opinion it should
compare as equals (==) or have argument (or another mechanism) how to
set whether compare by equal or identity.
As example I use array_diff_assoc but I think it will probably behave
simmilary with another array realted functions (array_diff%,
array_intersect%). In expected result I suppose comparing as equal
(operator '==').
In example you can see, that array_diff_assoc behaves in such way that 0
or '0' or '' is not same as false, but 1 or '1' is same as true. So
false is compared like '===' and true is compared like '=='. Because 0
is same as '0' and 1 is same as '1' I suppose, that this problem is only
for boolean false value.
Test script:
---
$arr1 = array('a' = 0, 'b' = 1,'c' = '0', 'd' = '1', 'e'
= '','f' = false, 'g' = true, 'h' = 0, 'i' = 1);
$arr2 = array('a' = false, 'b' = true, 'c' = false, 'd' = true, 'e'
= false, 'f' = false, 'g' = true, 'h' = '0', 'i' = '1');
var_dump(array_diff_assoc($arr1, $arr2));
Expected result:
array(0) {
}
Actual result:
--
array(2) {
[a]=
int(0)
[c]=
string(1) 0
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=53724edit=1
Bug #53230 [Com]: extracting file go to infinite loop
Edit report at http://bugs.php.net/bug.php?id=53230edit=1
ID: 53230
Comment by: tbrasta at gmail dot com
Reported by:vincent dot gibault at gmail dot com
Summary:extracting file go to infinite loop
Status: Open
Type: Bug
Package:Zip Related
Operating System: archlinux x86_64
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Your file is corrupted. It contains invalid crc, compressed and
uncompressed data lenghts of archived file.
It is libzip related bug. More details here
http://nih.at/listarchive/libzip-discuss/msg00074.html.
Previous Comments:
[2010-11-03 21:25:32] vincent dot gibault at gmail dot com
Hello,
here is the link: http://www.corrida-noel-issy.com/bug.zip
[2010-11-02 22:37:59] paj...@php.net
Please provide a link to the zip you are using for this bug.
[2010-11-02 22:06:20] vincent dot gibault at gmail dot com
Description:
The files joined contained: the script example.php and the archive
example.zip.
I can unzip the example.zip with the following commandlines:
unzip example.php
iconv -f UTF16 -t UTF8 data
( show the data xml values ).
But the test script failed to unzip the compressed file.
Test script:
---
$zip = new ZipArchive ();
$zip-open( 'example.zip' );
$f = $zip-getStream ('data');
while (!feof($f)) {
echo fgets($f);
}
fclose($f);
$zip-close();
Expected result:
not to go in infinite loop.
Actual result:
--
don't work. Please send me an email to have the example.zip
--
Edit this bug report at http://bugs.php.net/bug.php?id=53230edit=1
[PHP-BUG] Bug #54067 [NEW]: curl_multi_exec Timeouts
From:
Operating system: Win7XP
PHP version: 5.2.17
Package: IIS related
Bug Type: Bug
Bug description:curl_multi_exec Timeouts
Description:
Using a mayor version than 5.2.10 under IIS the function curl_multi_exec
timeouts,
just in IIS, I was testing a library twitter-async, I tried it on Apache
and it
works fine. (The script works great with version 5.2.10)
Test script:
---
https://github.com/jmathai/twitter-async/issues/closed#issue/84
EpiCurl.php, Line: 84
do{
$this-execStatus = curl_multi_exec($this-mc,
$this-running);
usleep(intval($innerSleepInt));
$innerSleepInt = intval(max(1,
($innerSleepInt*$this-sleepIncrement)));
}while($this-execStatus==CURLM_CALL_MULTI_PERFORM);
Expected result:
Array of results not a timeout
Actual result:
--
Timeout
--
Edit bug report at http://bugs.php.net/bug.php?id=54067edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54067r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54067r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54067r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54067r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54067r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54067r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54067r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54067r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54067r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54067r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54067r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54067r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54067r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54067r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54067r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54067r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54067r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54067r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54067r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54067r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54067r=mysqlcfg
Bug #26541 [Com]: a
Edit report at http://bugs.php.net/bug.php?id=26541edit=1
ID: 26541
Comment by: minime_abr_13 at hotmail dot com
Reported by:diogo at netmake dot com dot br
Summary:a
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: Windows 2000/Linux
PHP Version:4.3.3
Block user comment: N
Private report: N
New Comment:
Dammit, DOCUMENTATING names and TITLES! 'a' is a shit name.
Previous Comments:
[2003-12-06 10:22:15] e...@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
See http://www.php.net/empty
Note: empty() only checks variables as anything else will result in a
parse error. In otherwords, the following will not work:
empty(addslashes($name)).
[2003-12-06 09:35:06] diogo at netmake dot com dot br
Description:
i cant call a method(function) inside the function empty
Reproduce code:
---
if(!empty($this-GetOpen()))
{
...
...
...
}
.
.
.
function GetAbrir()
{
return $this-abrir;
}
Expected result:
i expected that the if return true or false.
error: Parse error: parse error, unexpected '(', expecting ')' in
C:\Inetpub\wwwroot\scriptcase2\devel\class\page\nmPageWizardForm.class.php
on line 125
and the variable abrir is empty initialized in the constructor of the
class
Actual result:
--
a
--
Edit this bug report at http://bugs.php.net/bug.php?id=26541edit=1
Bug #40034 [Com]: mssql_connect(): Unable to connect to server
Edit report at http://bugs.php.net/bug.php?id=40034edit=1 ID: 40034 Comment by: satyanarayana at egbsystems dot com Reported by:chris dot clos at lmcu dot org Summary:mssql_connect(): Unable to connect to server Status: Assigned Type: Bug Package:MSSQL related Operating System: Windows Server 2003 PHP Version:5.2.0 Assigned To:fmk Block user comment: N Private report: N New Comment: i am using PHP Version 5.2.5 , xampp , mssql windows 2005. i am not able to connect mssql server . it saying unable to connect Previous Comments: [2010-12-28 13:44:36] paj...@php.net @shutzel at gmx dot de Unrelated to this bug report, you simply have to install the MS SqlServer connection drivers, as usual :) [2010-12-28 13:27:54] shutzel at gmx dot de I had the same problem with mssql_connect() Unable to connect to server. Type in the shell php -m and if you get an error that the MSVCR71.dll is missing, just download it from this address http://www.dlldump.com/download-dll-files.php/dllfiles/M/MSVCR71.dll/download.html and copy it to c:\windows\system32 - thats it! Greetings from munich germany ;) [2010-07-18 16:57:39] opc dot three at gmail dot com Related to Bug #29074 [2009-10-19 16:08:48] guoxinzz at 163 dot com To correct a small error: mssql.connect_timeout = 60 http://blog.csdn.net/gumanren From mainland China [2009-10-19 16:05:48] guoxinzz at 163 dot com A temporary solution, the real problem is not found. Explore the question, please contact my technical blog http://blog.csdn.net/gumanren My E-mail:guoxi...@163.com or guoxi...@gmail.com My name is guoxin. Please view the English portion of the GOOGLE translation. Change PHP.ini configuration, as follows: [MSSQL] ; Allow or prevent persistent links. mssql.allow_persistent = On ; Maximum number of persistent links. -1 means no limit. mssql.max_persistent = -1 ; Maximum number of links (persistent+non persistent). -1 means no limit. mssql.max_links = -1 ; Minimum error severity to display. mssql.min_error_severity = 1000 ; Minimum message severity to display. mssql.min_message_severity = 1000 ; Compatibility mode with old versions of PHP 3.0. mssql.compatability_mode = Off ; Connect timeout mssql.connect_timeout = 5 ; Query timeout mssql.timeout = 60 ; Valid range 0 - 2147483647. Default = 4096. ;mssql.textlimit = 4096 ; Valid range 0 - 2147483647. Default = 4096. ;mssql.textsize = 4096 ; Limits the number of records in each batch. 0 = all records in one batch. ;mssql.batchsize = 0 ; Specify how datetime and datetim4 columns are returned ; On = Returns data converted to SQL server settings ; Off = Returns values as -MM-DD hh:mm:ss ;mssql.datetimeconvert = On ; Use NT authentication when connecting to the server mssql.secure_connection = on ; Specify max number of processes. -1 = library default ; msdlib defaults to 25 ; FreeTDS defaults to 4096 ;mssql.max_procs = -1 ; Specify client character set. ; If empty or not set the client charset from freetds.comf is used ; This is only used when compiled with FreeTDS ;mssql.charset = ISO-8859-1 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=40034 -- Edit this bug report at http://bugs.php.net/bug.php?id=40034edit=1
